Incidents

An incident is the story of a disruption: what happened, what you are doing, when it was over. It gets its own page, appears on the status page and in the history, and — if you want — triggers notifications.

The four phases

The order is a suggestion, not a requirement — you can go straight to Resolved if the disruption was over before you got to report it.

Setting Resolved stamps the resolution time and returns affected components to operational.

Severity

Minor, Major, Critical. Severity describes how much it hurts, independently of which phase the work is in. It drives the colour emphasis on the page.

Uptime does not use severity; it uses the state of the affected components. See Uptime.

What you configure

• Title — what appears in the list and in the notification. Describe the effect, not the cause: "Login failing" helps more than "Redis cluster degraded".
• Message — the first update, formatted. Through the API and MCP you may send HTML: paragraphs, emphasis, lists, headings and links stay; scripts, event handlers, iframes, inline styles and javascript: links are removed on save. The same goes for updates, maintenance and templates.
• Affected components — they take the state the severity implies: Minor → partial outage, Major and Critical → major outage. Through the API you can give each component a state of its own instead. That is what colours the status page.
• Occurred at — when it started. Defaults to now; backdate it if you only got to reporting later. Through the API you also give the end of an incident filed after it was over (resolved_at) and correct both later.
• Visible — off means the incident exists for your team only. It appears nowhere on the status page, its own page included; the components keep their state, and nobody is notified, your chat integrations included. For preparing one. Switch it on for an open incident and everything happens at that moment: the components show the disruption, subscribers and chat hear about it. Making an already resolved incident visible afterwards sends nothing. Switching a visible incident off again takes it off the page; the components go on showing the disruption until you resolve it or take them out of the incident. Switch it on again later and it is not announced a second time.
• Stickied — puts an open incident ahead of the other open ones on the status page, even when those are newer. Resolved incidents are listed by date in the history.
• Notify subscribers — sends the message to your subscribers. See Subscribers.
• Unlisted and Do not count towards uptime — see Unlisted entries.

Updates

An incident lives through its updates. Each carries its own timestamp and appears on the incident page as a timeline.

Writing an update can change the status at the same time — "Identified: a bad deployment, rolling back" is one update and one status change in a single step.

Per update you also decide whether subscribers hear about it. Not every interim note deserves an email.

The public link

The form and the list both offer Copy link — the address of the incident page under your status page domain. Paste it into a ticket, an email, a chat.

Approval by a second person

With four-eyes approval switched on for your status page, a new incident queues up first — it appears on the page and triggers notifications only once somebody else has approved it.

Templates

You do not rewrite recurring disruptions every time — see Templates.

Through the API

Incidents are the reason the API exists: your monitoring or your CI can open and close them without anyone opening a dashboard.

# Create
curl -X POST https://statuswerk.eu/api/v1/incidents \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Elevated error rate in checkout",
    "message": "We are investigating elevated 500s in checkout.",
    "severity": "major",
    "components": [{"id": "...", "status": "partial_outage"}]
  }'

# Add an update
curl -X POST https://statuswerk.eu/api/v1/incidents/{id}/updates \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -d '{"message": "Cause found, rolling back.", "status": "identified"}'

# Close
curl -X PATCH https://statuswerk.eu/api/v1/incidents/{id}/resolve \
  -H "Authorization: Bearer $STATUSWERK_TOKEN"

Full detail in the API reference.