Your First On-Call Shift: A Calm, Practical Checklist

At a glance

Your first shift asks four things of you: be reachable, acknowledge quickly, stabilise what you safely can, and pass on what you cannot. That is the whole job.

It does not ask you to know every service, diagnose unfamiliar systems alone, or fix things you have never seen. Those expectations are not part of the role, and if someone on your team implies otherwise, they are describing a staffing problem rather than your responsibility.

Most first shifts are quiet. Some are not. The preparation below is for the second kind, and it takes about an hour.

Before the shift starts

Do this while it is daylight and you are calm. Everything on this list is easier now than at 03:00.

Two more things worth settling in advance:

• Power and connectivity. A charged phone, a charging cable where you sleep, and a laptop charger already in the place you would work. If your home connection fails at 02:00, know whether tethering works and whether your VPN tolerates it.
• A place to work at 3am. Somewhere with a light you can turn on without waking the household, a surface for the laptop, and a door. Deciding this in advance removes a small decision from a moment when you have none to spare.

The first five minutes of a page

The point of a rehearsed sequence is that you do not have to think while half awake.

1. Acknowledge. Do this first, before reading anything closely. It stops escalation timers and tells everyone a human has it.
2. Read the alert and open the runbook. The alert should name a service and a condition. The runbook, if there is one, is linked from it.
3. Ask three questions. Is anything user-facing broken? Is data at risk? Is it getting worse? Those three produce a rough severity without a taxonomy.
4. Post one line. "I have the payments alert, looking now." Fifteen seconds of typing prevents several people from waking each other up to ask.
5. Decide: act or escalate. If the runbook has a step you understand and it is reversible, do it. If not, escalate now rather than after twenty minutes of reading.

Mitigation comes before understanding. Roll back, fail over, disable the feature, restart the worker. Root cause is a daytime activity.

What "acknowledged" means

Acknowledging a page means one thing: a human has seen it and is engaged. It stops the escalation clock.

It does not mean you have understood the problem, that you can fix it, that you are now solely responsible until it is resolved, or that you have promised anything about timing. Acknowledging and then escalating two minutes later is a normal, correct sequence.

The reverse failure is worse. If you delay acknowledgement while you investigate, the system assumes nobody responded and pages the next person, who wakes up to find you already working. Acknowledge first.

Escalating

Escalation is a routing decision, not a confession. You escalate when the problem is outside what you can safely resolve alone — which, on a first shift, is a lot of problems.

Escalate when any of these is true:

• You do not know what the alert means and the runbook does not tell you.
• The mitigation you would try is not reversible.
• The impact is growing while you work.
• You have been at it for a set time — twenty minutes is a reasonable default — with no progress.
• You are too tired to trust your own judgement.
• The change required touches a system you have never deployed to.

Say it plainly: "I have the checkout alert, error rate is climbing, I do not know this service, I need help." That sentence is complete and requires no apology attached to it.

If escalating feels costly on your team, raise it in a retrospective rather than absorbing the cost yourself. Late escalation is a predictable consequence of a norm that treats early escalation as failure.

When you do not know the service

This will happen, and it is expected on a first shift.

• Check whether the alert is user-visible. If nothing is broken for anyone, you have more time than the alert's urgency suggests.
• Look for a recent change. Check deployments, config changes, and feature flags from the last few hours first, because reverting a recent change is often the fastest safe mitigation available to you.
• Do not make exploratory changes to a production system you do not understand. Reading is safe; writing is not.
• Escalate to the service's owning team. That is what ownership is for.

Asking for cover

Life continues during on-call weeks. Asking for cover is an ordinary scheduling action.

Ask directly and specifically: name the window, name the reason only if you want to, and propose the swap. "Can you take Thursday 18:00 to Friday 09:00? I can take your Saturday." Then put the override in the scheduling tool yourself, and confirm the other person can see it. A verbal agreement that never reaches the schedule is a coverage gap wearing a friendly face.

If you are ill, in an emergency, or too tired to respond safely, hand the phone over. That is not a favour you are asking for; it is the system working.

What to record

Write as you go, in the incident channel or a scratch document. Timestamps matter more than prose.

• What the alert said, and when it arrived.
• What you observed: dashboard readings, error messages, log lines.
• Every action you took, with the time.
• Who you escalated to and when.
• What you did not try, and why.

You are not writing for posterity. You are writing so the next person does not start from zero, and so the review has facts rather than recollections.

Handing off

At the end of the shift, the incoming person needs current state, not history. Cover what is still open, what is unresolved but quiet, what you changed that has not been reverted, anything you silenced and when it should come back, and anything you expect to fire.

If an incident is still live at the boundary, hand over explicitly in writing and stay on the call until the other person confirms they have it.

After a disrupted night

Sleep loss is a real cost, not a soft one. Treat recovery as part of the shift.

• If you were awake for a substantial part of the night, do not work a normal day. Sleep first, and say in the team channel that you are doing so.
• Do not deploy anything significant while sleep-deprived.
• Write your notes before you sleep if you can manage a few lines; write the rest afterwards.
• Raise the alert that woke you at the next review. If it was avoidable, someone should fix it. If it was unavoidable, the runbook should be better.

If broken nights are frequent rather than occasional, that is a rotation design issue to bring to whoever owns the schedule.

A worked example

An illustrative example, not a real company.

An engineer takes their first shift on a team of six. At 02:40 their phone rings: the order-processing queue depth alert.

They acknowledge at 02:41. They open the runbook, which says a growing queue usually means the consumer has stalled, and the first step is to check the consumer's health endpoint. It returns errors. The runbook's next step is to restart the consumer, marked as safe and reversible. They restart it at 02:47. Queue depth begins falling at 02:49.

They post one line in the incident channel with the times, then wait ten minutes to confirm the trend holds. At 03:05 they write four sentences: alert, observation, action, outcome. They go back to bed.

At 09:30 they message the team that they were up for half an hour overnight and will start late. At the next review, the team asks why the consumer stalled, and adds a health check that restarts it automatically — which removes the alert from the paging list altogether.

Nothing about that night required deep knowledge of the service. It required a runbook with a safe first step, an alert that named a real condition, and a person willing to write four sentences afterwards.

What to do next

Work through this before your shift begins:

• Send yourself a real test page and confirm it arrives loudly on the device you will carry.
• Add the paging app to your do-not-disturb exceptions and verify it overrides silent mode.
• Log in today to every system you might need: dashboards, logs, cloud console, deploy tooling, VPN.
• Write down the escalation path on paper: primary, secondary, and the step after that, with names.
• Find the runbooks. Open the one for the alert most likely to fire and read it end to end.
• Ask your team two questions: what counts as a page here, and after how long should I escalate?
• Decide where you will work at 3am, and put a charging cable there.
• Agree with your team what project work you are expected to deliver this week, given the shift.