How do you set up uptime monitoring with on-call for a small team?

A team of two to ten engineers cannot staff a 24×7 rota and does not want to. The setup has to be quiet by default, page one person at a time, and have a clear path to a second person when the first does not answer. Four requirements follow:

• •Checks from outside the server, so an outage is seen even when the host and its monitoring agent are down
• •Confirmation before paging: one failed probe is network noise; two in a row is an outage
• •A rotation with a backup layer, overrides for holidays, and business hours if the team only promises daytime response
• •Escalation that stops the moment someone acknowledges, with a record of who was paged and whether the message was delivered

• •An HTTP check on every public URL that matters (the site, the API, the login page), every 1 to 5 minutes; every 30 seconds for the one URL customers hit first
• •An HTTPS check also reads the certificate: warn at 14 days, critical at 3, so expiry never becomes an outage
• •A TCP check on the database or Redis port from one of your own servers, not from the cloud, for targets on a private subnet
• •A heartbeat for every cron job and backup script: the job pings a URL when it finishes, and a missed ping pages you
• •DNS and domain-expiry checks for the domains you own, since an expired domain looks exactly like a dead server

In Opservo a monitor is declared down only after two consecutive failures, the outage is backdated to the first, and recovery is immediate with an info notice. A single blip never pages anyone.

Weekly shifts are easier to live with than daily ones for a small group: one handoff a week, in the schedule’s own timezone, with each person on call about one week in N. Add a second layer or let the next person in the rotation be the backup. Use overrides, not edits to the rotation, for holidays and swaps.

• •Two people: alternate weeks; each is the other’s backup; escalate to a founder or lead as the last step
• •Three to six people: one primary rotation, a backup layer offset by one position, business hours on if you do not promise nights
• •Distributed team: two schedules, one per region, with the escalation policy pointing at an after-hours schedule outside business hours
• •Page only on critical: a confirmed outage, a service down, a disk about to fill; warnings go to Slack or a digest

Write the steps as "after N minutes, who, by which channel". A policy that works for most small teams:

Step 1  at 0 min    primary      Slack + email + SMS
Step 2  at 10 min   primary      phone call
Step 3  at 20 min   backup       SMS + phone call
Step 4  at 40 min   team lead    phone call

Each step fires once. Acknowledging in the dashboard, from the mobile app or by pressing 1 on the call stops the chain. Keep the first step on channels people actually see; keep the phone call for the point where silence has already cost ten minutes.

Most teams end up with two tools: one that checks and one that pages. A few bundle both. The table shows what each covers and how it bills.

• •Uptime → Add: an HTTPS monitor per public URL at 1 minute, a heartbeat per cron job, a TCP monitor on the database checked from the app server
• •On-call → New schedule: timezone, weekly rotation, participants in order, a backup layer; members add their own overrides
• •Account → Profile → Paging: each person verifies a mobile number and ticks SMS, WhatsApp or call; the workspace connects its Twilio account once
• •On-call → Escalation policy: the four steps above; unacknowledged criticals are re-evaluated every 60 seconds and every attempt is listed in Page history
• •Status page: publish the monitors customers care about, so an outage answers the "is it just me" question before anyone emails support

Already on PagerDuty or OpsGenie? Paste a schedule export to import the rotation; people are matched by email and nothing is created without you. The existing outbound channels keep working beside it.