Incidents

An incident is Aloft’s record of a single outage on one monitor: it captures when the monitor went down, what caused it, and when it recovered. Aloft opens and closes incidents automatically as it checks your monitors — you don’t create them by hand. Your job is to watch them, hand them off, and write them up.

You’ll find everything in this guide under Incidents in the top navigation.

When an incident opens and closes

Aloft’s worker checks each monitor on its schedule and decides on an “effective” status before it acts. That gate is what keeps a single hiccup from paging you.

An incident opens when a monitor is confirmed down. A single failing check isn’t enough. The monitor has to fail a number of checks in a row equal to its confirmation count (set per monitor) before its status flips to down. Only that flip opens an incident — and at most one incident is open per monitor at a time.

An incident closes when the monitor comes back up. The next time a check genuinely succeeds, the monitor flips back to up and Aloft stamps the incident’s end time and total duration.

Degraded stays “in trouble”

A degraded result means the monitor answered but was too slow (for example, it breached its response-time threshold). Degraded is treated as still in trouble, not recovered:

• If a monitor is up and turns degraded, its status shows degraded but no incident opens.
• If a monitor already has an open incident (it’s down) and a check comes back degraded, the incident stays open. A slow response will not close an incident — only a clean up check does.

Alerts to your notification channels are sent on the same transitions: one “down” alert when the incident opens, one “back up” alert when it closes.

The Incidents wall

The Incidents page is a single wall of every outage across all of your monitors — the cross-monitor answer to “what should I care about right now?” (For the history of one specific monitor, open that monitor’s detail page instead.)

The four count tiles

Across the top you’ll see four tiles summarizing your org:

• Open — incidents that are currently unresolved.
• Unacknowledged — open incidents that nobody has acknowledged yet.
• Last 7 days — incidents that started in the past 7 days.
• Last 30 days — incidents that started in the past 30 days.

Filtering the list

Below the tiles are three filter chips. They re-filter the list of incidents from the last 30 days:

• Open — only unresolved incidents (the default view).
• Unacknowledged — unresolved incidents that haven’t been acknowledged.
• All in last 30d — everything from the past 30 days, resolved or not.

Each row shows the monitor name, an Open or Resolved badge (plus an Acked badge if acknowledged), the cause, when it started, and how long it has lasted (or is still running).

Acknowledging an incident

When an open incident hasn’t been acknowledged, its row has an Acknowledge button. Clicking it marks the incident as seen — a soft “a human is on it” signal that’s handy when several people are on call and you want a clear hand-off. The incident picks up an Acked badge and drops out of the Unacknowledged tile and filter.

Acknowledging does not stop alerts

Acknowledging is purely a status signal for your team. It does not silence or suppress any further notifications, and it does not resolve the incident. If you’re doing planned work and want to stop alerts and prevent incidents from opening at all, use a maintenance window instead.

Writing a post-mortem

Once an incident is resolved, its row gains a Post-mortem button. (Post- mortems are only available on resolved incidents — there’s nothing to write up while an outage is still unfolding.) Writing a post-mortem requires the member role or higher.

To write one:

1. On the Incidents wall, find the resolved incident and click Post-mortem.
2. Fill in the One-line summary — a short headline (up to 500 characters).
3. Write the Write-up in the body field. This field accepts Markdown, so you can use headings, lists, and links to structure the story (what happened, why, and what you changed).
4. Decide on visibility with the Show on the public status page toggle (see below).
5. Click Publish post-mortem.

You can come back and edit a post-mortem at any time — the button reads Edit post-mortem once one exists, and there’s a Delete button to remove it.

Public vs. private

The Show on the public status page toggle controls who can see the write-up:

• Off (private) — the post-mortem is internal. Only people in your org who open the incident can read it.
• On (public) — the post-mortem is published and will appear on any status page that includes the affected monitor, giving your visitors an honest account of what happened. Aloft shows the most recent public post-mortems for a page’s monitors.

You can flip a post-mortem between public and private later by editing it and toggling the switch.

Related

• Maintenance windows — suppress incidents and alerts during planned work.
• Status pages — where public post-mortems are shown.