Incidents Overview

See how Ionhour opens, tracks, and resolves incidents when a check or job goes down.

When a check or job goes DOWN, Ionhour automatically opens an incident so your team has one place to track it — from the first alert through resolution. This page walks through the Incidents screen, the incident detail page, and the actions you'll use day to day.

The Incidents page

The Incidents page is a two-column view:

Left column — Projects. Every project in your workspace, sorted so the ones with active incidents float to the top. Search narrows the list by name, and each project shows how many active incidents it currently has.
Right column — Issues. The incidents that belong to whichever project you've selected. Tabs let you switch between Active, Resolved, and All, and a filter box narrows by title. At the top you'll also see quick stats for the project: how many checks it has, how many incidents are currently active, and rolling MTTA (mean time to acknowledge) and MTTR (mean time to resolve) figures.

Each row in the issues list shows the incident's title, its status (Ongoing or Resolved), its severity, and how long it's been running.

Severity levels

Every incident carries one of four severities: P1 – Critical, P2 – High, P3 – Medium, or P4 – Low. Checks going fully DOWN typically open a Critical incident; late or degraded checks and dependency issues typically open a lower severity. You can change an incident's severity from its detail page while it's still active — once it's marked resolved, the severity is locked and shown as a read-only badge.

Declaring an incident manually

Not everything is caught automatically — sometimes you'll want to open an incident for something a customer reported, or an issue Ionhour didn't detect on its own. Click Declare Incident in the top-right of the Incidents page to do this.

Describe the incident

Enter a short summary of what's going on (this becomes the incident title). This is the only required field.

Set the severity

Choose one of the four severity levels (Critical, High, Medium, or Low). It defaults to Critical, and you can change it later.

Link a check (optional)

If the incident relates to a specific monitored check, pick it from the list. This connects the incident to that check for context, but it's optional — you can also leave it unlinked.

Add a description (optional)

Add any extra detail you already know. You can keep adding context once the incident is open, so don't worry about getting it perfect here.

The incident detail page

Clicking any incident opens its detail page. Along the top you'll find a back link, the incident's title (click it to rename), and its short display ID. The available actions here depend on where the incident is in its lifecycle:

Acknowledge — shown while the incident is active and no one has claimed it yet. Signals to the team that someone is on it.
Mark as resolved — shown while the incident is active. Opens a confirmation dialog (see below).
Reopen — shown once an incident is resolved, in case it turns out the issue wasn't fully fixed.

A ··· menu next to these holds a few more actions:

Merge incidents — shown while the incident is active. Combining incidents into one isn't available yet, so choosing this currently shows a "Coming soon" notice.
Publish to status page — shown while the incident is still active and hasn't already been published. It disappears once the incident is marked resolved, so publish before you resolve if customers need to be told.
Unmerge — shown in place of Merge incidents if this incident has already been merged into another one.
Copy link and Copy display ID — always available.

The page itself is split into two tabs: Overview and Post-incident.

Overview tab

Hero card — the at-a-glance summary: current status, severity, what triggered the incident (a check going down, a dependency going down, or a manually declared incident — incidents opened for a late or degraded check currently show as Unknown here), when it opened, how long it's been running, and who acknowledged or resolved it.
Summary — an editable write-up of what's happening. Anyone with permission can edit it as understanding of the incident evolves.
Activity — a combined feed of system events (opened, acknowledged, alerts sent, resolved) and notes your team adds along the way. You can filter the feed to show everything, just events, or just notes, and add your own notes from the composer at the bottom.
Escalation path — if the incident came from an on-call escalation, this card shows the policy that was used and each step: who was notified and when. It's hidden if no escalation policy is attached to the incident.
Properties & Roles — a compact side panel repeating the key facts (status, severity, type, timing) plus a place to assign an incident leader and an assignee so it's clear who owns the response. A related-resources card links back to the check, dependency, or status page announcement tied to the incident.

Post-incident tab

This is where your postmortem lives: root cause, customer impact, a timeline summary, and a checklist of follow-up action items (each with an owner and a completed checkbox). Writing a postmortem only becomes available once the incident is resolved — before that, this tab just tells you it's coming.

Resolving, reopening, and publishing updates

Acknowledge

Click Acknowledge as soon as someone starts looking into it. This records who's on it and when, so the rest of the team knows it's being handled.

Publish to your status page (optional)

If customers should know about the issue, open the ··· menu and choose Publish to status page — do this before you resolve the incident, since the option disappears once it's marked resolved. Pick a status page, adjust the title and impact level, write a short message, and optionally tag the affected components — this creates a public announcement linked to the incident.

Resolve

When the issue is fixed, click Mark as resolved. A confirmation dialog opens where you can optionally add a resolution message — confirming stops active alerting for the incident.

Reopen if needed

If the issue resurfaces, open the resolved incident and click Reopen. Confirm in the dialog that appears — this marks the incident active again and resumes alerting.

Let incidents resolve naturally when you can

When the underlying check recovers on its own, Ionhour resolves the matching incident automatically and records the real recovery time. Resolving manually is there for edge cases — like a manually declared incident, or when you want to stop alerting before the check has caught up.