Incidents

The record of every outage: when it started, who looked at it, what you did, and how long it lasted.

What an incident is

An incident is the file Enori opens when one of your monitors stops being healthy, and closes when it recovers. One monitor can have at most one open incident at a time — that is enforced in the database, not just in the UI, so a monitor that flaps for an hour produces one incident with a growing timeline rather than sixty.

An alert is a message that leaves the product. An incident is a record that stays in it. They are related but different:

Find them under Incidents in the sidebar (/dashboard/incidents), or from a monitor's own page.

When Enori opens one

Automatically, on the check cycle, when both of these are true:

1. The failure threshold is met. The monitor has failed at least Failure threshold consecutive checks — the setting on the monitor itself, where 0 means the first failing check counts. Raise it if a single blip shouldn't open a file.
2. The delay has elapsed. If you set Alert after N minutes down on the monitor, the incident waits with the alert. This is worth knowing precisely: the delay defers the incident too, not just the email. The monitor still goes red on your dashboard immediately, its uptime still takes the hit, and recovery polling still speeds up — but no incident exists until the wait is over.

The incident it opens looks like this:

When Enori does not open one

• During a maintenance window. Checks keep running and results are still recorded, but the whole alerting-and-incident path is skipped. A window is how you deploy without paperwork.
• While the multi-region quorum is still verifying. A single region reporting a failure schedules a re-check rather than declaring an outage; the incident waits for the verdict.
• Below the failure threshold, or inside the alert after delay — as above.

One thing that does not stop an incident: snoozing. A snooze holds back the alert at delivery time, for the person who set it. The incident still opens, still appears in your list, and still shows on your status page. If you want a quiet period with no incident, use a maintenance window.

Statuses

Six, and they come from two different traditions that Enori merges into one timeline.

"Active" means anything that is not Resolved. That is the single definition used by the Active tab, the dashboard's incident count, and the monitor-list badges — so a Triggered or Acknowledged incident counts as active, as you would expect.

Investigating / Identified / Monitoring are the public-facing three. They exist for the story you tell visitors on a status page: we're looking → we found it → we've fixed it and we're watching. Triggered and Acknowledged are the internal paging pair. You can move between them freely; nothing forces you through a sequence.

"Auto-recovered"

When a monitor recovers on its own, Enori resolves its open incident for you. That resolution is stamped as done by system rather than by a person, and the UI renders it differently: a green "Monitor recovered automatically" banner at the top, and Auto-recovered instead of Resolved on the timeline's closing entry. The resolution message reads "Monitor recovered automatically".

It is not a separate status — the status is Resolved, exactly as if you had clicked the button. Auto-recovered is the label for "Resolved, and nobody had to do it."

The practical read: an incident resolved by a person means someone fixed something. One that auto-recovered means the service came back — which may mean it was fixed elsewhere, or may mean it was transient. That distinction is why the label exists.

Severity

Severity is not frozen at open time. If a Degraded monitor gets worse and goes Down, the open incident's severity is raised and a line lands on the timeline: "Severity escalated to Major: «error»". If it improves, the incident stays open and records "Improvement — now Minor, incident remains open." And if the failure reason itself changes — a timeout becomes a 500 — that's recorded too: "Error changed: «new error»".

That is deliberate. An outage that changes shape is still one outage, and its history is more useful than three incidents that each tell a third of the story.

Working an incident

Open one from the Incidents list, or from the monitor's page.

Acknowledge

Acknowledge says a human has this. Two things happen:

• The escalation ladder stops. If an escalation policy was working its way up through levels, it stops there and nobody further up gets paged.
• The timeline records who and when — your name if your sign-in provides one, your email otherwise, "API key" if the acknowledgement came through the API, or "one-click link" if it came from the Acknowledge link in an escalation page (that link is not signed in, so it has no name to record).

The Acknowledge button on the detail page appears while the incident is Triggered — the state escalation-policy monitors open in. Incidents that opened as Investigating (no escalation policy) show Resolve and Add Update instead, since there is no ladder to stop. You can always acknowledge through the API, the MCP tools, or the Ack button on the Incidents list.

Acknowledging an incident that has already resolved does nothing. That's a guard, not a quirk: without it, clicking a stale button would reopen a closed outage and corrupt your mean-time figures.

Add an update

Add Update posts a message to the timeline and, optionally, moves the status. The picker offers the three public states — Investigating, Identified, Monitoring — because this is the control your status-page visitors are reading. Every update also pushes a notification to your status-page subscribers.

Updates are append-only. You can't edit or delete one; post a correcting update instead.

Resolve

Resolve closes it, with an optional resolution message. The escalation ladder stops, the duration is stamped, mobile Live Activities end, and status-page subscribers are told it's over.

Resolving does not touch the monitor. If the monitor is genuinely still down, the next failing check opens a new incident — resolving is a statement about the record, not a fix.

Write it up

Once an incident is resolved, a Post-incident review section appears on its page. Click Write postmortem and you get a starter template:

## What happened
## Timeline
## Root cause
## Impact
## Fix
## Prevention

Fill in what's useful, delete what isn't. Then either Save draft — private, visible only to you — or tick Publish to public status page and Save & publish, which puts the write-up under this incident for anyone reading your status page.

Two things to know before you publish:

• It is stored and shown as plain text. The template uses ## headings out of habit, but nothing renders markdown — line breaks and spacing are preserved exactly as you typed them, on your page and on the public one. Write it to read well as plain text.
• Publishing is reversible. Untick the box and save, or clear the text, and it goes back to being a draft. Re-publishing keeps the original publish timestamp.

You can write and edit a review at any time after the incident resolves, and edit it forever afterwards. There is a 20,000-character ceiling.

Evidence

For an HTTP-based monitor, Enori captures what the server actually sent back on the first failing check of the incident and keeps it on the incident's page under Evidence:

• Response body — up to 64 KB, rendered in a locked-down sandboxed frame (no scripts run, ever — the body came from somewhere you don't control). Longer bodies are truncated and say so.
• Response headers — as a key/value table.

Three deliberate limits:

• First failing check only. Not every check in the outage — one artifact per incident, captured once. A later check that fails differently is described in the timeline ("Error changed: …") but does not overwrite the evidence.
• The body is fetched through a link that expires after 10 minutes. Reload the page if you leave it open and come back; you get a fresh one.
• Older incidents have none. Evidence capture is newer than some of your history, and the section says "Evidence not available for older incidents" rather than pretending.

Beside it, on monitors with tracing enabled and a plan that includes it, an AI root-cause analysis of the correlated trace may appear. See Traces.

Mean time to acknowledge, mean time to resolve

These are the two numbers you quote in an SLA conversation, so their definitions matter more than most.

Both are computed over a rolling 90-day window, across your whole account — every monitor, every severity, pooled. Neither is per-monitor and neither is configurable.

MTTA — mean time to acknowledge

The average of (acknowledged − started) over every incident acknowledged in the last 90 days.

• Only acknowledged incidents count. An incident nobody ever acknowledged is not in the average at all — it does not count as an infinite wait, and it does not count as zero. It is simply absent.
• The 90 days is measured from the acknowledgement, not from when the incident started. An incident that opened four months ago and was acknowledged yesterday is in the window.
• If nothing has been acknowledged in 90 days, there is no figure.

MTTR — mean time to resolve

The average of (resolved − started) over every incident resolved in the last 90 days.

• Only resolved incidents count. An outage still running right now is not dragging the number up — it will land in the average the moment it closes.
• Auto-recovered incidents are included. They are resolutions like any other, and on most accounts they are the overwhelming majority. So MTTR here is closer to "how long the average outage lasted" than to "how fast our team responds" — for that, read MTTA.
• The window is measured from the resolution, same as MTTA.
• Deliberately not a lifetime average: one bad night three years ago should not permanently define your figure.

Where to read them

Today these are served by the API, not shown in the dashboard:

returns mttaSeconds, mttrSeconds, your total incident count, your active count, and your five most recent incidents. It needs the incidents:read scope — see API keys and the API reference.

If a figure is null, it means the 90-day window contains nothing to average — not zero.

The Incidents list

Incidents in the sidebar.

Each row shows the monitor, the status and severity pills, the title, the error, when it started, how many checks failed, the duration ("Ongoing for 12m" while open, "Duration: 12m" once closed), and who acknowledged or resolved it.

Arriving from a monitor — clicking its incident count — filters the list to that monitor and shows a Filtered to: «monitor» chip with an ✕ to clear it. The tab counts then describe that monitor only. That arrival deliberately lands on All rather than Active, so clicking through from a monitor that is currently up doesn't show you an empty page.

The list is not a live ticker: it refreshes when you act on something and when you come back to the tab. Reload if you have been staring at it through an outage.

Retention

Two consequences worth planning around:

• Incident retention is not your plan's data-retention setting. Your plan governs how long raw check results are kept (30 / 60 / 90 days). Incidents outlive that on every plan — the record of an outage survives long after the individual checks that detected it.
• Deleting a monitor deletes its incidents, immediately and permanently, along with everything else attached to it. If an incident's history matters — for an SLA claim, an audit, a post-mortem you haven't finished — export or copy it before you delete the monitor. The same applies to deleting your account.

There is no way to delete a single incident from the dashboard. If an incident is wrong or embarrassing, resolve it and — if it's on a public page — take it off the page rather than trying to erase it.

Incidents on your public status page

If a status page has Show incident history on, it publishes incidents for the monitors it covers: up to 20 of them, from within the page's history window. Visitors see the title, status, severity, start and end times, and every timeline update — plus the post-incident review, if you published one.

They do not see the error message, the evidence, the failed-check count, the region, or who acknowledged it. Those stay internal.

An incident can be kept off public pages entirely by setting isPublic to false on it through the API (PUT /api/incidents/{id}). Incidents default to public, and there is no toggle for this in the dashboard today — if you need one incident hidden, that's the API route.

Incidents and teams

Incidents belong to the account that owns the monitor. A teammate you have shared a monitor with — Viewer or Editor — cannot list, open, acknowledge or resolve your incidents from the dashboard or the API, and cannot write a post-incident review. See Teams.

What they do get is the notification: a bell entry and a push when a shared monitor goes down and when it recovers, without the inline Acknowledge / Resolve buttons your own copy carries.

One route does reach them, and it is the supported one. If a colleague needs to take an outage, put them on an escalation policy built on the team. The page it sends carries a one-click Acknowledge link, and clicking it acknowledges the incident for real — same effect as your own Acknowledge, and the ladder stops. The timeline records it as "one-click link" rather than their name, since the link is not signed in. Their role grants nothing here; what grants it is holding the signed, single-use, 48-hour link your policy sent them. Opening, updating and resolving the incident stay with you.

Creating an incident by hand

You can open one yourself, on a monitor you own, through the API or the MCP tools — useful when you want a record of something Enori couldn't detect (a partner outage, a bad deploy you rolled back before a check caught it).

with a monitorId, a title (up to 200 characters), and optionally a description, status, severity, isPublic, and a backdated startedAt.

It is deduplicated. If that monitor already has an open incident, you get that incident back with a 200 instead of a second one being created — the one-open-incident-per-monitor rule holds for manual incidents too. Add to the existing one with an update rather than trying to open a parallel record.

FAQ

Why did my monitor go down but no incident appeared?

Six possibilities, in the order worth checking: the monitor was inside a maintenance window; it hasn't yet failed Failure threshold consecutive checks; you set Alert after N minutes down and the wait hasn't elapsed; a multi-region quorum is still verifying; the monitor already has an open incident from an earlier failure; or the monitor is paused.

Why is there still an incident when the monitor is back up?

Auto-resolution happens when the check cycle observes the recovery. If the monitor is up in your browser but the incident is still open, the next check hasn't landed yet. If it stays open after that, resolve it by hand — and note that resolving does not stop a new incident opening if the monitor fails again.

I snoozed the monitor. Why did an incident open?

Snoozing suppresses the alert, at the moment it would be delivered, for you. It does not suppress the incident. Use a maintenance window if you want no record either.

Can I reopen a resolved incident?

No. Resolution is final; if the problem recurs, a new incident is opened. Attempting to acknowledge a resolved incident is deliberately a no-op — see Acknowledge.

Does acknowledging stop the alerts?

It stops the escalation ladder — nobody further up the policy gets paged. It does not retroactively unsend anything, and it does not stop the recovery notification when the monitor comes back.

What's the difference between an incident and an alert episode?

An alert episode is the delivery-side object: it tracks one condition firing, being acknowledged, snoozed and clearing across your channels. An incident is the outage record: one per monitor at a time, with a public-facing timeline and a status page presence. A single outage typically produces both.

Why do my MTTA and MTTR disagree with what I calculated?

Most likely one of three definitional details: both are account-wide, both are 90-day rolling, and each counts only incidents that reached the relevant state within the window — never-acknowledged incidents are absent from MTTA entirely, and open incidents are absent from MTTR. See the definitions above.

How do I get an incident list for a customer report?

Two routes. For a specific period and monitor, an SLA report on a calendar-monthly SLO includes the incidents in the period, with a verification checksum — that is the document to send a customer. For raw data, GET /api/incidents?monitorId=… with limit and offset (max 200 per page).

Can I filter incidents by date?

Not on the server. GET /api/incidents takes monitorId, status, limit and offset — no date range. Filter on startedAt after you fetch.

Reference

Related documentation

• Alerts — channels, alert rules, escalation policies, on-call schedules, alert episodes
• Maintenance windows — the way to have downtime without an incident
• SLOs — error budgets, and the SLA report that lists incidents for a period
• Teams — who can and cannot act on your incidents
• Notifications — the bell, and what a teammate receives
• Traces — the AI root-cause analysis that can appear on an incident
• API reference — every incident endpoint

Last updated: 2026-08-18. Feedback or corrections: support@enori.io