On-Call

On-call started as one thing: SigNoz alerts, routed to whoever’s rotation covers the moment an alert fires, with tiered escalation if nobody acks. This cycle added a second thing to the same rotation: new defect requests page the same person, and their response is measured against a target.

What on-call owns#

SigNoz alerts. Unchanged from before: an alert fires, the schedule’s currentAssignee gets paged, and unacknowledged alerts escalate through the schedule’s configured tiers.
New ad_hoc and bug requests. The moment one is submitted, whoever’s on call for that org right now gets a push notification naming the request and confirming they’re the one on call. task requests are never routed this way, on-call is for defects and unplanned work, not planned work.

On-call routing is opt-in by having a schedule at all. If an org has no on-call schedule configured, a new defect request notifies nobody and nothing errors, it’s simply not routed. The same is true mid-schedule: if the moment a request lands falls in a coverage gap (see below), nobody is paged for it either. Either way the request still exists and still shows up wherever requests normally do, on-call not firing just means nobody got tapped on the shoulder for it.

The triage queue#

/on-call/triage lists every request still in submitted status for the caller’s org, ad_hoc and bug only, newest first. Moving a request to wip is what “triaged” means, and it drops off this list the moment that happens.

This is the whole untriaged backlog, not a view scoped to “since your shift started.” A new on-call engineer picking up a schedule sees everything still waiting, not just what arrived after they came on, that’s a better definition of “what do I need to look at right now” than a shift-scoped window would be.

SLA targets#

Every ad_hoc and bug request carries two clocks, both measured from when it was submitted: time to triage (moved out of submitted) and time to resolve (marked complete).

Priority	Triage within	Resolve within
Urgent	30 minutes	4 hours
High	2 hours	1 day
Normal	1 day	1 week
Low / None	No target	No target

Both clocks start at submission, not at triage, the resolve target is submitted-to-resolved, not triage-to-resolved. A late triage is a permanent breach: triaging it, even minutes later, does not undo the miss. These targets are the same for every org today, there’s no per-org configuration.

Breach reporting#

A schedule’s reporting tab, the same view that already shows alert MTTA, MTTR, volume, and per-person load, now also breaks down SLA breaches by priority for that org’s ad_hoc/bug requests. Because this lives inside a schedule’s own reporting tab, it only exists for orgs that have on-call configured at all.

This is visibility only. A breached SLA does not page anyone or escalate anything, that’s a deliberate scope decision, and it’s a different thing entirely from alert escalation above, which already existed and is unrelated.

Shifts, overlaps, and gaps#

A schedule doesn’t have to tile the day perfectly. Two shifts can overlap (a handover window covered by two people) or leave a gap (nobody on call for a stretch, e.g. no overnight coverage for a low-severity product), both are legal roster shapes now, not construction errors.

When shifts overlap, priority is list order: whichever shift is listed first in the schedule is the one treated as on call and the one paged, regardless of which shift’s window actually started more recently, seniority or shift length don’t factor in. A gap means nobody is on call for that stretch, both alerts and new defect requests are silently unrouted rather than assigned to someone who doesn’t exist.

The read-only weekly calendar at /on-call shows a schedule’s shifts for manpower planning. The schedule editor and the calendar’s own visualization are still catching up to what the underlying model now allows, check the app for what you can enter and see today rather than assuming everything above is already editable end to end.