Alerts & notifications

Get notified when a backup fails, when a restore test can't confirm your data, or when a scheduled backup doesn't run at all — by email, Slack, or a signed webhook. On by default, in every plan.

A backup product that fails silently is worse than no backup product. Norcube Backup alerts you when something goes wrong — and, just as importantly, when something that should have happened didn't. Alerting is on by default, included in every plan, and never paywalled.

With zero configuration, alerts go by email to every member of your organization with a verified address. The Notifications page (Backup → Notifications, under Operations) lets you narrow the recipients, add Slack and webhook channels, and toggle individual alert types.

What triggers an alert

Alert	Fires when
Backup failed	A backup run ended in an error — at launch, during the dump, or detected afterwards by the reconciliation worker.
Restore test failed	An automated restore test errored, or completed but could not confirm your data came back. A backup that runs but doesn't restore is exactly what restore testing exists to catch.
Backup missed	The dead-man's switch: a scheduled backup window passed without a backup running, or a job sat waiting to start well past its window. Most tools only alert on failures — a scheduler that silently stops is the more dangerous case.
Restore failed	A manual restore did not complete.
Recovered	A database that was failing succeeds again. Sent once, and only if you were actually notified about the failure.

Two things deliberately do not alert: restore tests that passed with warnings (they show amber in the dashboard instead — the data restored), and long-running backups (a legitimate multi-hour dump is not an incident; if the job actually died, the reconciliation worker detects it and that failure alerts).

No alert storms

Alerts are deduplicated per database and alert type:

The first failure notifies immediately.
Repeat failures of the same kind are counted, not re-sent, for a cooldown window (6 hours).
If it is still failing after the cooldown, you get one follow-up ("3rd consecutive failure"), not one email per run.
When a run finally succeeds, the counter resets and a single Recovered notice closes the loop.

Channels

Email

The default channel. Recipients are the addresses you list on the Notifications page; when the list is empty, every organization member with a verified email receives alerts, so a new organization is covered from day one. Every email links to the affected datasource and, when a log exists, the failing run's log.

Slack

Paste a Slack incoming-webhook URL and alerts post to your channel, color-coded by severity (red for failures, amber for missed backups, green for recoveries), with a link back to the datasource.

Webhook

Point Norcube at any HTTPS endpoint and every alert POSTs as JSON:

{
  "id": "5f6…",
  "type": "backup_failed",
  "organizationId": "8b4…",
  "dataSourceId": "9c5…",
  "dataSourceName": "production-db",
  "subject": "Backup failed: production-db",
  "payload": {
    "jobId": "dc7…",
    "engine": "postgres",
    "errorSummary": "connection refused",
    "stage": "run"
  },
  "createdAt": "2026-08-11T15:04:05Z"
}

Set a signing secret and each request carries an X-Signature: sha256=<hex> header — an HMAC-SHA256 of the raw body — plus an X-Norcube-Event header with the alert type. Verify the signature before trusting the payload. The secret is write-only: once saved it is never displayed again, only replaced.

Delivery is at-least-once with exponential backoff; a failing endpoint never blocks the other channels.

Test the pipeline

The Send test alert button pushes a synthetic alert through every configured channel and reports the result per channel — including the exact error when an endpoint rejects it (for example endpoint returned HTTP 404). Use it after any settings change; it exercises the same code path real alerts take.