Something not behaving?

Signata isn't recording anything

Almost always one of three things, in order of likelihood:

• It isn't armed. Signata records only while armed. Check the menu bar icon: solid means armed, outline means standing by.
• The trigger is switched off. Settings ▸ Triggers gates USB, volumes, displays and audio independently. Audio output ships off because Bluetooth headphones reconnecting would otherwise fill your timeline.
• The event happened while the Mac was asleep. Signata isn't running then. It records from wake onward — see Limits.

Alerts aren't arriving

Signata never queues an alert against a channel that can't succeed, so an unconfigured channel produces no delivery status at all rather than a row of failures. Work through these:

• Is the channel enabled and configured? Both are required. Telegram and webhooks both ship disabled, because a bring-your-own channel shouldn't be live before you've supplied credentials.
• Telegram: the bot must already be in the chat or channel you're sending to. A bot that has never been added can't post, and Telegram reports that as a rejection rather than an error.
• Webhooks: HTTPS only. Plain HTTP is refused, because the URL alone is enough to post to most services.
• Were you offline? Alerts queue and retry with backoff when connectivity returns, up to eight attempts. Diagnostics shows what's pending.
• Did a delivery genuinely fail? Timeline shows the status per channel, and failures can be retried by hand. A failure on one channel never hides a success on another.

Verifying your log

The Timeline window reports chain status directly. To check a log without running Signata at all — which is the point of publishing the format — use the standalone verifier:

tools/verify-signata-log.py \
  ~/Library/Containers/com.stacknscope.Signata/Data/Library/Application\ Support/Signata/security-events.jsonl

Exit codes: 0 intact or pre-chain only, 1 broken or entries missing, 2 unreadable.

"Chain not started" is not a fault. Entries written before hash chaining existed carry no links, and Signata will never retroactively hash its own history — an application quietly re-sealing its past records is precisely the thing this format exists to detect.

If verification reports a break, note the entry number and don't overwrite the file. The break is caught by the entry after the one that changed, so the reported number is one past the alteration.

Too many events, or the wrong ones

• Maintenance wakes: Signata classifies wake reason and doesn't alert on Power Nap, Time Machine, RTC timers or network wakes. They're still recorded — a dark wake is forensically interesting even when it isn't worth a notification.
• Docking and undocking: display add and remove fire on a routine dock. Turn the display trigger off in Settings ▸ Triggers if you dock daily.
• Audio churn: already off by default. If you turned it on and regret it, that's why.

Permissions

Evidence Mode is off by default and each capture type has its own opt-in and its own macOS permission. Denying either is safe: events keep recording, and Signata degrades rather than nagging.

• Camera denied: System Settings ▸ Privacy & Security ▸ Camera. Note that with the lid closed the camera sees nothing regardless of permission.
• Screen Recording denied: System Settings ▸ Privacy & Security ▸ Screen & System Audio Recording. macOS may require a relaunch after granting.
• Start at Login stuck on "approval needed": macOS holds new login items for confirmation. Open System Settings ▸ General ▸ Login Items and approve Signata there.

Refunds

If Signata doesn't do what this site says it does, write within 30 days of purchase and you'll get your money back. No form, no justification required. A product whose entire argument is honesty shouldn't make its refund policy the exception.

Reporting a bug

Useful reports usually include:

• macOS version and Mac model
• Signata version, from Settings ▸ About
• What you expected, and what happened instead
• Whether Signata was armed at the time
• The relevant Timeline entries — read them before sending. Event summaries can contain device names and volume paths, and evidence files should never be attached to a support email

Never send a Telegram bot token, a webhook URL, or a screenshot showing either. A webhook URL alone is usually enough for anyone holding it to post to your channel.

Security issues

Email support@stacknscope.com with "security" in the subject. Please don't open a public issue first. You'll get an acknowledgement, and credit in the release notes if you'd like it.