Incidents & severities

What is an incident?

HowlOps has two levels. An alert is the raw signal in the Alerts list (a monitor failing, a heartbeat going quiet, an external alert arriving). An incident is an alert that has been promoted into the Incidents list so it can be tracked and coordinated. Detection, notification, and escalation all happen at the alert level, you are paged whether or not the alert ever becomes an incident.

For exactly how an alert opens and how it is delivered, see Step 1: where alerts come from in the flow page. For the promotion mechanics (automatic rules and the manual button), see Alerts and incidents are two levels.

When the service recovers, the underlying alert auto-resolves (and any incident it was promoted into resolves with it); see Step 6: recovery and resolve. You can also create incidents manually for planned maintenance or issues not yet detected by monitors, see Manual incidents below.

For the lifecycle states an alert (and any incident promoted from it) moves through, and the Acknowledge, Silence, and Unacknowledge actions, see Acknowledge, silence, unacknowledge. Promotion to an incident and the is_major flag are separate markers, they do not change those states. An alert can be acknowledged whether or not it is an incident.

Severities

Each alert carries a severity that controls escalation timing and notification channels. HowlOps uses three levels:

Severity	Use case
critical	Full outage. Auto-promotes to an incident and always pages, even through quiet hours.
warning	Degradation or partial failure. Standard on-call routing.
info	Minor or informational. No on-call page by default.

Default severity is configured per monitor, on the monitor's own edit page (Monitors → the monitor → Edit).

For what actually opens an alert (failed checks, SSL problems, missed heartbeats, and how the threshold and deduplication work), see Step 1: where alerts come from in the flow page.

Manual incidents

Create a manual incident for situations not captured by monitors, for example a database migration that causes degraded performance, or a known upstream provider issue.

1. Go to Incidents in the sidebar.
2. Click + Manual Incident.
3. Select the affected monitor(s) and write a description.
4. The incident appears on the status page immediately.

Incident notes

While working on an incident, add internal notes to track your investigation:

• Notes are internal only (not visible on the public status page).
• Notes are stored and rendered as plain text (no Markdown formatting).
• Use notes for root-cause analysis, team communication, and post-mortem documentation.

Status page visibility

Active incidents appear automatically on your public status page (any monitor on that page that is down shows there without action). To replace the generic label with a human explanation, post a public update:

1. Open Status pages → Configure and scroll to the Incidents section (step 7).
2. Click Post public update on the incident, pick a phase (Investigating, Identified, Monitoring, or Resolved), and write a short message.
3. Submit. The update appears on the status page immediately, in chronological order.

Posting a public update queues a status-page subscriber notification; an internal note never leaves the workspace. Opening and resolution notifications follow the same status-page subscriber path. See Respond to incidents on a status page.

Correlation: multiple alerts, one view

When several monitors fail within a short window, HowlOps automatically correlates their alerts into a single correlated group and shows a grouping banner ("N monitors affected") on the related alerts. This is automatic, there is no "Correlation Groups" screen to configure, and correlation is a view/banner only: every individual alert still fires and pages on its own (correlation reduces confusion, not the number of pages).

The correlation window and the minimum number of alerts that form a group are per-workspace settings, currently adjustable through the API (/api/v1/correlation-groups/config) rather than a dedicated settings screen.

To actively suppress child alerts when a shared dependency fails, use monitor dependencies instead (see Monitors). While a parent monitor is down, HowlOps holds alerts for the monitors that depend on it.

Deleting incidents

You can delete a single incident from its row, or select several on the Incidents board and delete them together. Deleting is permanent: the incident and its timeline are removed for everyone in the workspace, and the confirmation says so before you commit.

If part of a bulk delete does not go through, the ones that failed stay selected and the message tells you how many. Nothing is silently dropped.

Deleting an incident is not the same as closing it. Closing keeps the record and the history; deleting removes it. Prefer closing unless the incident is genuinely noise you do not want to keep.

History retention

Resolved incidents are retained according to the workspace's current plan. See the plan limits reference for the canonical values. You can filter the history by monitor, date range, or status from the Incidents view.