Alerts and on-call
Alerts and on-call covers everything between detecting a problem and getting a human to it. Rules are evaluated every minute at /observability/alerts, routed through Alert channels (/observability/alert-channels) and Workflows (/observability/workflows), measured against SLOs (/observability/slos), escalated by Escalation policies (/observability/escalation-policies), and recorded as Incidents (/observability/incidents) and on the Incident timeline (/observability/timeline).
What it is
Detection without response is noise. Owlpane treats alerting as a pipeline: a rule watches live telemetry, a firing event selects the channels that should hear about it, an escalation policy widens the audience if nobody acks in time, and — once a responder is engaged — an incident record keeps ownership, acknowledgements, and follow-up in one place.
The same surface handles alerting and the on-call rotation, so the escape hatch from "something is wrong" to "someone is looking" is one workspace.
Key capabilities
- Rules checked every minute against live telemetry: error spikes, slow responses, failing jobs, log-pattern matches, and new errors. History rows link back to Traces and Logs at the fire time.
- Channels for alerts, SLO burn warnings, and uptime incidents: Slack, Microsoft Teams, Discord, Google Chat, PagerDuty, Opsgenie, signed webhooks, Jira, and ServiceNow — with workspace notification defaults so new checks inherit your stack.
- Workflows that run steps when an alert fires or resolves, or when an incident is declared — send a webhook, or notify a channel (a Jira or ServiceNow channel opens a ticket).
- SLOs with a reliability target, an error budget, and multi-window fast/slow burn alerts. Burn history shows the event log, budget chart, and deploy markers.
- Escalation policies that merge step-0 channels at dispatch and fire later steps after a delay if the alert is still open and unacknowledged.
- Incidents and timeline for external Jira and ServiceNow issues, with acknowledgements syncing back when inbound webhooks are configured.
- Scheduled reports (
/observability/reports) to email a dashboard snapshot on a cadence.
Where it lives
| Surface | Console route | What it does |
|---|---|---|
| Alerts | /observability/alerts | Rules, rule health, notification volume, and notification history. |
| Alert channels | /observability/alert-channels | Destinations, signing secrets, and workspace notification defaults. |
| Workflows | /observability/workflows | Steps triggered by alert fire/resolve or incident declaration. |
| SLOs | /observability/slos | Reliability targets, error budgets, and burn-rate alerts. |
| Escalation policies | /observability/escalation-policies | Delayed, multi-step notification for unacknowledged alerts. |
| Incidents | /observability/incidents | External Jira and ServiceNow issues opened from alerts. |
| Declared incidents | /observability/declared-incidents | Incidents declared by you. |
| Incident timeline | /observability/timeline | Chronological incident events. |
Plans
Alerting breadth is not gated behind a paid tier: every alert channel kind, the Slack app, importing on-call schedules, and the on-call schedule count are available on all plans. See Plan and billing for the workspace plan details.
How data gets in
Rules read the same ingested telemetry as the explorers — metrics, logs, and spans. Channels are outbound, so the only inbound requirement is that the signal a rule watches is already flowing to ingest.owlpane.com.
- Metric ingestion and Log ingestion — the streams threshold and pattern rules watch.
- Integration library — uptime and other checks that feed incidents.
- Ingest keys & authentication — how telemetry reaches the workspace.
Concepts
| Term | Meaning |
|---|---|
| Rule | A condition checked every minute against live telemetry. |
| Firing | The state a rule enters when its condition is met. |
| Acknowledge | A responder taking ownership of a firing alert to stop repeat paging. |
| Escalation policy | A policy that adds channels after a delay if an alert stays unacknowledged. |
| SLO | A reliability target with an attached error budget. |
| Error budget | The allowed shortfall against an SLO's target. |
| Burn rate | How fast the error budget is being consumed. |
| Incident | A tracked issue, either declared by you or opened in Jira or ServiceNow. |
How the pieces connect
Detection is only the first step. A firing rule selects channels, an escalation policy widens the audience on a delay, and an incident record preserves ownership and acknowledgements. SLOs sit alongside as a slower signal: rather than a single threshold, they warn when the error budget is burning faster than the target allows. The same notify path is shared by every channel kind, so switching a destination does not change how a rule is written.
Related
- Alerts task guide — rule types and the alert lifecycle.
- Owlpane on-call overview — unified inbox, mobile apps, and quiet hours.
- Dashboards · Metrics · Traces — the surfaces rules and SLOs draw on.
- AI — human-in-the-loop triage and approval.
Last updated