An alert is OpShift's representation of an incident. Every page, every Slack notification, every phone call, every entry on the activity timeline traces back to an alert. Alerts are created by monitors going down, by webhook calls from your services, or by Slack listeners promoting channel messages.
Severity levels
OpShift uses a five-level severity scale. Higher severities page harder and ignore more quiet-hours rules.
| Field | Type | Description |
|---|---|---|
sev0 | Critical | Total outage. Pages everyone, ignores quiet hours. |
sev1 | Major | Production-impacting. Pages primary on-call immediately. |
sev2 | Significant | Degraded function. Pages on-call, respects policy timing. |
sev3 | Minor | Surfaces in Slack, no phone escalation by default. |
sev4 | Informational | Logged for audit; useful for tracking, not paging. |
Alert lifecycle
- created — a brand-new alert. On-call is notified per the matching notification policy.
- occurrence_added — a repeat hit matched an open alert via group key. The occurrence count goes up; no new page fires.
- filtered — a webhook filter rule matched and dropped the payload before an alert was created. Returned with a reason.
- reopened — a recently-resolved alert received a new occurrence inside the reopen window, so the same alert is reopened instead of a new one being created.
- acknowledged — an on-call engineer claimed the alert. Escalation halts.
- resolved — the underlying issue is fixed. The alert closes.
Automatic grouping
A hundred failures shouldn't be a hundred pages. OpShift groups related occurrences in two ways:
- Explicit grouping — set a
group_keyon the source (a webhook POST, a monitor reason) and any future occurrences with the same key fold into the open alert. Best for known-shape incidents (a specific job, a specific endpoint). - Implicit grouping — when no group key is supplied, OpShift derives one from the title and source so visually identical alerts still coalesce.
A good key is stable across occurrences but specific to the failure shape —
for example, db:write-timeout:checkout-svc. Avoid putting timestamps or
request IDs in the key; that defeats grouping.
Reopen detection
When an alert is resolved, OpShift keeps a short reopen window. A new occurrence with the same group key inside that window reopens the original alert instead of creating a new one — useful for incidents that flap right after a fix is deployed.
Where alerts come from
Alerts can be raised by three different sources:
- Monitors — a missed heartbeat or an explicit
status: "down"ping fires a monitor-down alert. See Monitors. - Webhooks — your code posts to a webhook endpoint and an alert is created from the payload. See Webhooks.
- Slack listeners — messages in a watched channel that match your rules become alerts. See Slack listeners.
Whatever the source, the alert object that emerges is the same — and the routing through notification policies, on-call schedules, and Slack interactivity is identical.