When something has gone wrong with Notes In Confidence and you have decided to send a bug report, the developer is going to want the diagnostic log. The button that produces it lives in Advanced > Danger Zone (same tab as the delete-vault options, but the log buttons are separate). This article covers what the log contains, what it does not contain, the Preview log button you should always click first, and one strict rule: do not edit the ZIP file before sending it.
What the log is for
The log is a chronological record of app activity that the developer can read to reconstruct what your browser tried to do when the bug happened. Typical entries are: when sync attempts started and finished, what error codes Drive returned, which page load triggered which save, how long a password rotation took, which permission scopes were granted. It is metadata about the app's own operations, not about your clinical content.
The log has two main uses.
Reporting a bug. Something visibly went wrong — sync got stuck, a backup did not download, the dashboard kept redirecting, the Cancel button did the wrong thing — and you would like the developer to look at it. The log is what lets them work out what your browser was doing without needing access to your machine.
Forensics on your own state. Even without sending it anywhere, you can preview the log and read it yourself. The Activity tab of Advanced > Drive > Recent sync activity shows recent sync events; the diagnostic log goes deeper — pre-unlock errors, migration steps, every individual flush and pull, every danger-zone confirmation. Mostly only useful if you understand the codebase, but the Preview log button lets anyone read it.
What is in the log — and what is not
The application has worked hard to keep clinical content out of the log. The developer reviews the entries that get written every time a new event type is added, with the explicit goal of catching anything that might leak.
In the log. Event timestamps. Event names like drive.push_ok or danger.delete_local_run_start. HTTP status codes returned by Google. Names of fields that changed in a record (schedule_day, frequency) but not the field's old or new value. Counts (5 rows pushed). Browser version strings. Tab and window state. Sync engine state transitions.
Not in the log, by design. The content of any note. The name or identifying details of any client or supervisee. Your password. Your Google email address. Your Drive vault file ID (the ID names the file but contains no clinical signal). The text you typed into any form. Any cell value that would allow a reader to reconstruct what you wrote.
A residual risk worth being honest about. Despite the design effort, some risk of information leakage remains. A field name like schedule_day is harmless on its own; a long run of error messages from Drive could in theory carry a fragment of a filename. The Settings card carries this warning explicitly: "Every effort has been made to keep client and personal data out of the log, but some risk of information leakage remains. Only download this bundle if you need it to troubleshoot an issue with the app or to send to support — and only send it to a support address you trust."
The Preview button — always click this first
Before you click Download Diagnostic Log, click Preview log. A dialog opens with the entire log rendered as plain text, exactly the way the recipient will see it. You can scroll through it. If anything in there gives you pause, you can close the preview without downloading anything, and nothing has left your device.
The preview is not a redaction step — it is a consent step. The log you would have downloaded is exactly what the preview shows. Skipping the preview is not technically dangerous, but it is the only opportunity to read the bytes you are about to send.
Downloading — what you actually get
Clicking Download Diagnostic Log produces a ZIP file with a name like:
tn-diagnostic-log-2026-05-18T17-16-05-000Z.zip
The ZIP contains exactly three entries:
| File | What it is |
|---|---|
log.txt |
The diagnostic log itself, in plain text. |
log.txt.sig |
A 64-character hex string — an HMAC signature of log.txt. |
README.txt |
A one-line note for the recipient: "Do not edit anything in this zip." |
You can open log.txt in any text editor to read what is in it. The signature in log.txt.sig is what the developer's support server checks to confirm the log has not been edited since it was downloaded. The signature is over the exact bytes of log.txt as stored in the ZIP — character-for-character, including line endings, including any quirks.
Please send the ZIP unchanged
This is the most important paragraph in this article.
When you are reporting a bug, send the ZIP file exactly as it was downloaded. Do not unzip it. Do not re-zip it. Do not open log.txt in a text editor, change a single character, and save. Do not strip blank lines, remove timestamps, or "tidy up" anything. The signature in log.txt.sig is computed over the bytes that came out of the download, and any change — even an invisible one like a Windows text editor "fixing" line endings or adding a UTF-8 BOM — invalidates it. The support server then rejects the bundle.
If you want to redact something, the correct flow is: open Preview log before you download, read the contents, and if you see something you do not want to send, do not download at all. Report the issue without the log. Or contact the developer first and describe the problem in your own words.
There is no good reason to need to edit the log file before sending. The signing is tamper-evidence, not provenance — its job is to catch accidental edits and corrupted uploads. If you genuinely have a use case for editing it, please email the developer first and describe what you are trying to do.
What "tamper-evidence" actually means here
The signature does not prove the log came from you, and it does not encrypt the log. The HMAC key is bundled in the application's static JavaScript, so anyone who reads the source code can extract it and forge a signature on a hand-edited log if they want to. The point of the signature is much smaller: to catch the everyday case where a well-meaning user opens the file in Notepad, deletes a line, saves, and reports a different bug than what actually happened. That is the failure mode the signature exists for. It is not a cryptographic provenance claim.
If you understand that and you still need to redact, the honest answer is to delete the ZIP, take a screenshot of the relevant part of the Recent sync activity panel in Advanced > Drive instead, and send that.
How to send the bug report
- Decide what you want to report. A short description of what you did, what happened, and what you expected is more valuable than a wall of log lines.
- In Advanced > Danger Zone, click Preview log and skim the contents. If anything makes you uncomfortable, stop here and report without the log.
- Click Download Diagnostic Log. The ZIP lands in your Downloads folder.
- Attach the ZIP to your email exactly as it is. Do not unzip, edit, or re-zip.
- Send the email to a support address you trust. The Terms of Service and Privacy Notice both make clear that the operator does not provide product support, so the address you send to is whichever feedback / community route you arrived at the app through.
What to do next
If the bug is about a specific banner, the article Banners at the top of the app explains every banner the app shows, what they mean, and what each one's button does. If the bug is about sync stopping, Resolving the read-only banner covers the most common cause. If the bug is about deletion, Deleting your vault — the Danger Zone options explains exactly what each Danger Zone button does. If you are reporting because you forgot your password, the diagnostic log will not help you recover — read I forgot my password for the honest options.