These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Server Monitoring
- Features
- On-call operations
On-call operations
Review service coverage and keep responder actions visible in the incident chronology.
OverviewOn-Call Schedule×
Server Monitoring · On-call operations
New
On-Call Schedule
On call shifts
| Id | Starts at | Ends at | Escalation level | Service | Responder | |
|---|---|---|---|---|---|---|
| IDD-585 | 13 Oct | 21 Oct | 940 | SRV-8963 | ||
| IDD-905 | 13 Oct | 20 Oct | 190 | SRV-4453 | ||
| IDD-947 | 04 Oct | 12 Oct | 920 | SRV-1292 | ||
| IDD-335 | 03 Oct | 05 Oct | 140 | SRV-4466 | ||
| IDD-479 | 10 Oct | 19 Oct | 930 | SRV-5130 |
6 of 6 records
IDD-585On call shifts · OCS-50633
Starts at13 Oct
Ends at21 Oct
Escalation level940
ServiceSRV-8963
What you can do
Put a named responder behind the shift
An on-call shift connects a service to a responder, with start and end times and an escalation level. The incident records its assigned person separately. That distinction matters when a service has an on-call plan but a specific case is assigned to another responder. The Monitoring Operator can consult the shift, assign the incident and record the first page event. The responder acknowledges and records the action taken. If the case changes hands, later response events show who handled the escalation.
Suppose the database service fails an availability check near a shift change. The first responder is on the current shift, while the next responder starts soon. The operator opens the incident and pages the current responder. That responder acknowledges and writes an investigation update. If work continues beyond the shift, the team updates assignment and records an escalation event for the person receiving it. The chronology should show the page, acknowledgment and next handoff at their real times. A shift boundary by itself does not resolve an incident.
How the work is organized
- Coverage. Keep shift start, end, service and responder together for the team reviewing an alert.
- Escalation. Use the escalation level and a response event to record the actual handoff.
- Incident history. Preserve attributed updates so the incoming responder can see what has already been tried.
What to agree during setup
Agree which services require scheduled coverage and who owns shift maintenance. Set escalation levels in language the team uses and choose a procedure for overlapping or uncovered shifts. Decide how the monitoring operator confirms the receiving responder before changing assignment. The person listed in a shift may be unavailable; the actual response should be clear from the incident and event records, not inferred from the rota alone.
Check the handoff on an actual case
Set up adjacent shifts for one service and create a failed check near the handover. Ask the Monitoring Operator to identify the current responder, open the incident and record a page. Have that responder acknowledge, add an update and hand the unresolved issue to the next person. The incoming responder should be able to read the preceding action and add their own update. The Service Owner then checks whether there is one current assignee and whether the response events identify each actor.
Repeat with an escalation to a higher level. The shift record should explain who was expected to take the page, while the event records show what actually happened. If a page received no acknowledgment, the operator keeps the incident open and escalates through the agreed path. Recovery is recorded only after the service check and impact evidence have been reviewed.
What your team sees
- On-Call Schedule — See service coverage by start, end, responder and escalation level.
- My Incidents — Find work assigned to the current responder.
- Open Incidents — Review cases waiting for acknowledgment or further investigation.
Follow the work through
Use incident response for assignment and acknowledgment. See outage assessment when the case affects service availability.
What it keeps track of
Data model- On call shifts
- On Call Shifts records for IT service and asset operations.
- Incidents
- Incidents records for IT service and asset operations.
- Response events
- Response Events records for IT service and asset operations.
- Incident updates
- Incident Updates records for IT service and asset operations.
- People
- People records for IT service and asset operations.
- Services
- Services records for IT service and asset operations.
Who uses it
Permissions- Monitoring Operator
- , Incident Responder, Service Owner
Set up Server Monitoring your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.