On-Call
On-Call is Autoheal's native paging system: who is on duty right now, who gets woken up when an alert fires, and how that page escalates until someone acknowledges it. It replaces a standalone paging tool, and because it runs inside Autoheal, a page arrives with the investigation already underway.
On-Call is a separate add-on module. If you don't see On-Call in the sidebar, it isn't enabled for your organization, so contact support@autoheal.ai.
Everything below lives under On-Call in the sidebar, which has five tabs: My On-Call, Active Pages, All Schedules, All Escalation Rules, and Status Pages.
The four building blocks
| Object | What it is |
|---|---|
| Team | A group of people who own services and share schedules. Members have roles. |
| Schedule | Who is on-call for a team, over time. Owns a timezone. |
| Rotation | A layer within a schedule: an ordered list of people and a shift length. |
| Escalation rule | Which alerts page, whom to page, and what happens when nobody answers. |
A schedule answers who is on duty. An escalation rule answers who gets paged and in what order. They are separate on purpose, so one escalation rule can page a schedule, a specific person, or a Slack channel.
Schedules and rotations
A schedule is built from one or more rotations, each a layer with its own participants and shift length.
- Participants are ordered. The rotation cycles through them in order, one shift each.
- Shift length is arbitrary: a week, a day, or twelve hours.
- Layers stack by priority. Each rotation has a layer order, and the lowest-numbered active layer wins at any instant. Higher-numbered layers act as fallback coverage. Layer
0is the top layer.
This is how you express "primary and secondary": a weekday-business-hours rotation on layer 0, and a broader always-on rotation on layer 1 to catch nights and weekends.
Each schedule carries a timezone, so shift boundaries land at sensible local hours for the people on it.
Overrides
An override replaces whoever the rotation would have picked, for a fixed window such as a doctor's appointment or a swapped weekend. You give it a person, a start and end time, and optionally a reason. Overrides win over rotations, and the timeline shows whether the current on-call came from a rotation or an override.
Previewing before you commit
Rotation changes are easy to get wrong, so you can preview a timeline before saving. Autoheal renders the resulting shift-by-shift schedule from a proposed configuration without persisting anything, letting you confirm the handoffs land where you expect.
Escalation rules
An escalation rule has two halves: which alerts it applies to (matchers), and who it pages (nodes).
Matchers decide what pages
Matchers are label conditions evaluated against the alert's own labels. Each matcher is a label, an operator, and a value; the operators are =, !=, =~, and !~ (the last two being regex).
Matchers are grouped as OR-of-AND: within a group every matcher must match, and the rule fires if any group matches. So "severity is critical AND service is checkout, OR team is payments" is one rule with two groups.
Two behaviors worth internalizing:
- A rule with no matchers never pages. There is deliberately no catch-all. Not every alert should wake someone, so an unmatched alert creates no page rather than falling through to a default. An escalation rule with an empty matcher set is inert until you add one.
- First match wins. When several rules match, they are tried in their configured order and the first one that matches and has at least one delivery target creates the page. A matching rule with no targets is skipped rather than silently swallowing the page.
Because matching runs against the alert's own labels, you can route on any label without it being part of your alert grouping configuration.
Nodes decide who gets paged
A rule's nodes are its escalation levels, in order. Each level has:
- Targets: a person, a schedule (which resolves to whoever is on-call at that moment), or a Slack channel. A level can have several.
- A timeout: how long to wait for an acknowledgement before moving to the next level.
You can also set a repeat count to cycle back through the levels if the page is still unanswered, and working hours (timezone, days, start and end) so a rule behaves differently outside business hours.
Pages
A page is one paging event. It appears under Active Pages and moves through four states:
| Status | Meaning |
|---|---|
| Triggered | Escalation is running; nobody has acknowledged yet. |
| Acknowledged | Someone took it. Escalation stops. |
| Resolved | Terminal. The underlying issue is done. |
| Timed out | Escalation ran through every level (and repeats) with no acknowledgement. |
Pages are either triggered by an alert or created manually, and carry an urgency of high or low.
Three actions are available on a page:
- Acknowledge: stop the escalation; you have it. Each acknowledgement is recorded with who and when.
- Resolve: close it out. Always available on a page that isn't already resolved, so a timed-out page can still be cleared from the queue.
- Re-page: restart escalation on a page whose escalation is no longer running. This is the recovery path for a page that timed out because nobody was reachable.
A page detail view shows every notification attempt: the level it came from, the target, the channel, the person it resolved to for schedule targets, and whether delivery succeeded, failed, or was skipped. When a page escalates through a schedule, this is how you see who was actually reached.
When new alerts join an existing issue
If more alerts arrive for something already paged, Autoheal does not create a duplicate page. It re-escalates the existing page if that page was acknowledged or timed out, and does nothing if escalation is still running. A resolved page is terminal, so a new occurrence gets a new page.
Paging is fully deterministic. It runs before, and independently of, any AI triage, so the matcher evaluation above is the whole decision, with no model in the loop.
My On-Call
My On-Call is the personal view: whether you are on-call right now, which schedules you are on, and a calendar of your upcoming shifts. It's the tab to check before going into a weekend.
Shift handoff notifications
Each schedule can notify people when a shift changes hands. Handoff notifications are off by default and configured per schedule:
- A Slack post to a channel you choose, announcing the handoff.
- SMS to both the outgoing and incoming person.
Notifications fire when the rotation actually advances in real time, not when you edit a schedule. Editing a rotation does not spuriously announce a handoff.
Importing from PagerDuty
If you already run on-call in PagerDuty, schedules and escalation policies can be imported through the PagerDuty integration rather than rebuilt by hand. Imported objects keep a link back to their source, so you can tell an imported schedule from one authored in Autoheal.
Status pages
Where the rest of On-Call is about telling your team that something is wrong, a status page is about telling your users. It's a public page showing the current health of your services, active incidents in real time, past incident history, and an email subscription, and it's the page you link to from your app, docs, or support channels.
Autoheal status pages follow the pattern your users already know from Atlassian Statuspage: a page lists services, incidents describe what's happening and which services are affected, and each service shows an at-a-glance status.
The pieces
- Status page: one public page (e.g. "Acme US"). You can have several, such as one per region or product. Each has its own public web address.
- Services: the components shown on the page (e.g. API, Dashboard, Webhooks). Each has a status: Operational, Degraded performance, Partial outage, Major outage, or Under maintenance.
- Incidents: a post with a lifecycle (Investigating → Identified → Monitoring → Resolved) and a running timeline of updates. An incident names the services it affects and how badly; their status updates automatically.
- Updates: a free-form single message for anything that isn't a lifecycle incident: a heads-up, a scheduled-maintenance note, or an announcement. No status, no effect on service health.
- Subscribers: end users who opt in by email (double opt-in) to be notified when you publish or update a post.
How service status is decided
You don't set a service's overall status by hand. Autoheal derives it from your open incidents: a service shows the worst impact among all unresolved incidents that list it. Resolve the last incident affecting a service and it returns to Operational automatically.
Public vs. private
Every page has a single visibility switch:
- Private (default): the page exists and you can build it out, but it is not served publicly.
- Public: the page is live at its web address for anyone to see.
Flipping a page to Public is how you publish it. Posts are live the moment you create them and there is no separate draft step, so a private page lets you set everything up before anyone can see it.
A public page can also be served on your own subdomain (e.g. status.yourcompany.com) instead of the default address.
What your users see
A published page shows two sections: Active incidents (unresolved, with their latest updates) and Recent updates (resolved incidents and update posts from the last 15 days, newest first). Visitors can subscribe by email to be notified of new and updated posts.
See Status Pages for creating a page, posting incidents, custom domains, and how subscriptions work.