Alerts

An alert says that something needs someone: a registration deadline is getting close, a jurisdiction was blocked automatically, a webhook endpoint keeps failing, the ledger doesn't balance. Each alert has a code from the catalogue (for example REG_AUTO_BLOCKED), a severity, a message in plain words and a link to the page where you act on it.

Severities and where alerts go#

Alerts belong to a mode: test-mode alerts go to the test-mode inbox and the test-mode Slack channels, with a test-mode label in emails. Test mode is a complete parallel world, so you can practice the whole compliance workflow there.

Who sees and who is emailed#

Each alert is about one area, such as registrations, the ledger or webhooks. The inbox shows an alert to every member who may read that area at the alert's legal entity or brand, in its mode, so it never shows more than the rest of the console does. Owners and admins see every alert. Acknowledging or resolving an alert needs write access to its area (for example a tax manager for registration alerts, finance for ledger alerts).

Email goes to the roles that handle the area, at the alert's legal entity or above:

A tax manager limited to one legal entity is emailed only about that entity. A member without live access isn't emailed about live alerts.

An approval request (APPROVAL_REQUESTED) is emailed to the people who may decide on it: owners, admins and organization-wide finance and tax managers who may run the requested operation themselves, except the person who asked. It is shown in the inbox to everyone who may read approvals, and resolves itself when the request is approved, rejected or expires (approvals).

Acknowledge and resolve#

• Acknowledge (alerts.acknowledge): someone is on it. The alert stays unresolved; if the same problem is raised again, its occurrence count goes up instead of a new alert appearing.
• Resolve (alerts.resolve): it's dealt with. If it happens again, a new alert is raised and delivered again. Many alerts also resolve themselves when the condition clears, for example when the registration a REG_BLOCKED_EXISTING_CUSTOMERS alert is about is registered.

Delivery#

Ownrecord delivers an alert after it is saved, never as part of the change that raised it. A critical ledger alert (LEDGER_INVARIANT_BROKEN) also notifies Ownrecord's on-call engineers, with only its code, your organization's ID and a link: never amounts, accounts or customers. Each email recipient and each Slack channel is reached once per alert. When one fails (Slack down, a mail outage), only that one is tried again: after 1 minute, then 5 and 15 minutes, 1, 3, 6 and 12 hours. The inbox shows how an alert was delivered.

Slack#

Owners and admins add Slack channels in Settings → Alerts (or with alert_settings.slack_channels.create): a name, the channel's incoming webhook URL, and whether it gets high and critical alerts or critical ones only. Up to 10 channels per mode.

• The webhook URL is stored encrypted and never shown again; the console shows its host and last characters.
• URLs must be https on a public host. Any Slack-compatible incoming webhook works.
• Every message is signed like a webhook: an Ownrecord-Signature: t=…,v1=… header with the channel's own signing secret (whsec_…, shown once when you add the channel). Slack ignores it; a relay in front of Slack can verify it.
• Send test message posts a test message now and shows what the webhook answered.

Alert codes#

Reference#

• Operations: alerts.list, alerts.get, alerts.acknowledge, alerts.resolve, alert_settings.get, alert_settings.update, alert_settings.slack_channels.create, alert_settings.slack_channels.delete, alert_settings.slack_channels.test.
• Errors: alert_resolved, slack_webhook_url_invalid, slack_channel_limit_reached (errors).
• Related: compliance tasks, registrations.