DOCS

Incidents & severities

Understand how monitors and heartbeats resolve into incidents, lifecycle states, and severity levels.

For the end-to-end flow (how an alert opens, how it is delivered, and how it resolves) and the full alert lifecycle, see Alert & incident flow. This page covers what an incident is: severities, manual incidents, notes, status-page visibility, correlation, and history retention.

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 in Settings → Monitors.

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.

Go to Incidents in the sidebar.
Click + Manual Incident.
Select the affected monitor(s) and write a description.
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:

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

Posting an update does not send a subscriber email. Subscribers are emailed when an incident is first detected and when it resolves. 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.

History retention

Resolved incidents are retained in the incident history for 365 days on every plan. You can filter the history by monitor, date range, or status from the Incidents view.

Was this page helpful?