Skip to content

Incidents

An incident opens when a monitor misses a beat or breaks a rule. Incidents lists them across every monitor, newest first. Each monitor’s Incidents tab shows its own.

  • Filter with State: Every state, Open, Recovering, Recovered or Resolved.
  • Tick Show archived incidents to include incidents of archived monitors.
  • Still open marks an incident that hasn’t closed. Acknowledged means someone owns it.
State What it means
Open The problem is happening.
Recovering Good beats are back. SignalSitter is confirming recovery.
Recovered Recovery was confirmed and the incident closed.
Resolved Someone closed it by hand.

The Incidents list showing an Open missing-beat incident on Orders export, a Recovering and Acknowledged one on ETL hourly, a Recovered one on Orders export and a Resolved and Acknowledged one on Legacy cron

Open an incident to see:

  • What happened: when it was detected, opened, confirmed and closed, plus the Incident ID.
  • Recovery: confirming beats received so far, and who acknowledged it.
  • Incident evidence and feedback history: for a rule, the reading that broke it.
  • How this incident unfolded: a chart of the measurement with the incident’s events. Open Event detail to list every event in order.
  • Callback deliveries: every alert sent for this incident.

The buttons sit at the top of the incident. Each opens a short confirmation.

  • Acknowledge: says someone owns the response. The state doesn’t change and detection continues. Offered while the incident is open or recovering and nobody has acknowledged it.
  • Add note: adds a line to the incident’s events for anyone reading later.
  • Resolve: closes the incident. Works on a recovered incident too.

Notes are 1 to 1024 characters on one line. A note is required for Add note and optional for the other two.

An open missing-beat incident on orders-export, not yet acknowledged, with Acknowledge, Resolve and Add note buttons, What happened and Recovery details, and a Callback deliveries section showing one delivery Retrying after four 503 responses, with the next retry in 1 minute and 4 attempts remaining

Callback deliveries shows each alert sent to your callback endpoint and its state: Queued, In flight, Retrying, Delivered, Failed, Dead-lettered or Outcome unknown. Each lists its attempts, with the response your endpoint gave. A retrying delivery shows Next retry at and Attempts remaining.

To send one again:

  1. Press Request redelivery on the delivery.
  2. Press Schedule the redelivery.

One more signed attempt is queued. Your receiver should ignore an event ID it has already handled.