Troubleshooting

Send a test first

In Incidents, open Settings in the sidebar and choose Send a test under Notices. It goes to every destination of the project and by email to you, and the page says for each one whether it was sent, or the error. Each incident's Notices sent says the same for its real notices. More about the test.

Nobody got an email

• The kind doesn't go to Its people. On Settings → Notices, What goes where, check that Its people is ticked for it under Incidents. A kind with nothing ticked goes nowhere.
• They don't open the project in Incidents. The project's people are those whose role at id gives them Incidents. Check the project's People at id.
• The email was filtered. A notice's subject starts with its severity and reference, such as [SEV1] INC-12 declared: …. Look in the spam folder, and allow the sender.

Nothing arrives in Telegram or Slack

• The destination isn't ticked. A new destination gets nothing until it is ticked for each kind under What goes where.
• The bot can't post in the chat. Add the bot to the group or channel, and check the chat id: a group's starts with -100, a channel can be its @name.
• The bot token or the webhook was revoked. The destination then shows the last error. Remove it and add it again with a new token or webhook, then send a test.

A notice that failed isn't sent again, so fix the destination before the next one.

A change told nobody

Not every change is a notice. An update posted on its own, a lowered severity, a new lead, a follow-up and the write-up send nothing; an internal note never goes out. Post the update with Post and move to … to send it with the next status. When people are told lists what is.

There's no Declare an incident

• You are a Viewer. Declaring and running incidents takes Triage or Admin in the project. Ask one of its admins at id.
• The project hasn't added Incidents. Its people then see Incidents' product page instead of its pages; the workspace's owners add it on the Subscription page at id.
• The subscription has ended. The pages are read only until it is renewed.

A field is refused

• It began can't be later than now, or more than 30 days back.
• A follow-up's Due day is today or later, and its owner is one of the project's people.
• The write-up is saved once the incident is resolved, with at least What happened. A declined incident has none.

The API answers 401

The server secret is missing, wrong, revoked, or made for another product. Send it as Authorization: Bearer sk_…, with the secret made beside Incidents on Settings → Keys. Its row there says when it was last used.

The API answers 422

A field is missing or wrong, and errors names it: severity must be sev1, sev2 or sev3, and a title is needed. If the message says the project doesn't have Incidents, the key's project hasn't added it.

One outage opened two incidents

The calls had no dedupe_key, or not the same one, or the first incident was resolved before the second call came. Send the same key for the same thing every time: while an incident with it is open, a call joins it. One incident per outage.

Resolving answers 404

No open incident has that dedupe key: a person resolved or declined it already, or it was opened with another key. There is nothing left to resolve, so your system can treat it as done.

The API answers 429 or 402

429: more than 120 calls in a minute with one secret. Wait for the seconds in Retry-After, and call on a change rather than on every check. 402: the project's subscription has ended; its link leads to renewing it.

An incident isn't on the status page

• Nobody chose Show on the status page for it. The head of its page says On the status page when it is shown.
• It was resolved more than 14 days ago, or it was declined.
• Status isn't connected to the project's Incidents with its own server secret. Connect Status.
• It was shown a moment ago: Status reads the incidents every minute.