How Do Quiet Hours and Escalation Chains Work Together for a Small Team?

Quiet hours and escalation chains solve two different problems that get lumped together as "alerting." Quiet hours decide whether a routine notification reaches your phone right now, based on the time of night and how urgent it is. An escalation chain decides who gets notified next if an urgent one goes unacknowledged. Used together, a two-person team can silence deploy pings and daily digests overnight while still guaranteeing that a genuinely down production system reaches someone — without building a formal on-call rotation to do it.

Most small teams get this backwards. They either mute everything after 10pm (and sleep through a real outage) or leave every channel unmuted (and stop trusting notifications within a month because half of them are noise). The fix isn't a bigger tool — it's separating "should this wait until morning" from "who answers if the first person doesn't."

What Quiet Hours Actually Do

Quiet hours are a per-user setting: a start time, an end time, and your own timezone. While that window is active, notifications below a configured priority are held rather than pushed — not discarded. When the window ends, anything held is released so you see what you missed. The setting also takes a bypass level: high, urgent, or never. That's the honest part of the design — "never" means even an urgent alert is held until morning, which is a real choice some people make deliberately for a side project, and the setting says so plainly rather than pretending everything urgent always gets through.

What quiet hours do not do is decide who else should be told. That's a separate mechanism, because "nobody woke up to my alert" and "I want a second person notified if I don't respond" are different failure modes with different fixes.

What an Escalation Chain Actually Does

An escalation policy is an ordered list of steps, each with a delay in minutes and a target — a specific person, a shared conversation, or a webhook. When an incident opens and stays unacknowledged, the runner checks whether enough time has passed since the incident opened for the next step to fire. Timing is measured from the incident's open time, not from "now plus delay" at the moment a step fires — so if the checking process itself goes down for ten minutes, it doesn't quietly push every deadline back by ten minutes when it comes back online. It fires whatever is genuinely overdue and picks up from there.

There is exactly one stop condition: someone acknowledges the incident. Acknowledging halts the chain immediately, for free, because it's the same signal the retry loop already watches. There's no separate "cancel escalation" action to remember, and no way for a policy to silently keep paging people after someone has already said "I've got it."

What This Is Not

This is not an on-call rotation. There's no calendar, no rotating schedule, no handoff at a fixed hour. A step in a policy points at one specific person, one conversation, or one webhook — not "whoever is on call this week." For a team of one or two, that's usually the right amount of machinery: you don't need a rotation when there are only one or two humans to rotate between. If your team eventually needs shift-based on-call with a calendar, that's a heavier category of tool, and it's worth being upfront that it's outside what a linear escalation chain does.

Why the Two Need Each Other

Without quiet hours, an escalation chain just means more people get woken up by the same noisy alert — you've automated the annoyance, not fixed it. Without an escalation chain, quiet hours just means the one person on quiet hours sleeps through something real, because there's no second target to fall back to.

Together, the sequence for a genuinely urgent incident looks like this: step one notifies you; if your own quiet hours are active and the alert's priority doesn't meet your bypass level, it's held until your window ends — exactly like it would be for a non-urgent message. If the incident is marked urgent and your bypass allows it, it reaches you regardless of the hour. If you don't acknowledge within the first step's delay, step two fires — a co-founder, a shared incident channel, or a webhook into whatever system you already watch. Their own quiet hours setting governs whether it reaches them the same way. No single quiet-hours setting can silently swallow the entire chain, because each step evaluates the rule for its own target, not the whole policy.

Setting Up an Escalation Policy

Escalation policies are created through the API with a Bearer key (see the escalations reference) or from the dashboard. A minimal two-step policy — notify you immediately, then a shared conversation if 10 minutes pass with no acknowledgment — looks like this:

curl -X POST https://pingwire.dev/api/v1/escalations.php \
  -H "Authorization: Bearer pw_live_xxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Production",
    "steps": [
      { "order": 1, "delay_minutes": 0,  "target_type": "user",         "user_id": 42 },
      { "order": 2, "delay_minutes": 10, "target_type": "conversation", "conversation_id": 7 }
    ]
  }'

Steps are replaced wholesale on every save, never patched one at a time — a policy read every minute by the runner can't be caught mid-edit holding a duplicate step order or a gap. A step whose target doesn't resolve is refused at save time, not discovered the first time it fails to reach anyone.

Quiet hours are a personal setting, not a machine one — you set your own window from your account settings (start, end, and how urgent an alert has to be to bypass it), and it applies automatically to any notification routed to you, including ones a policy sends your way.

How Many Steps Should a Small Team Actually Use?

Two or three. The first step is you (or whoever owns the system that alert covers). The second step, if you use one, is a shared conversation or a co-founder — someone who can at least see the alert exists, even if they can't personally fix it. A third step, if you add one, is usually a webhook into something you already watch daily, as a last-resort net rather than a person. More than three steps for a two-person team is complexity with no one left to notify — if step three still hasn't reached a human, adding a step four rarely helps; it means step one or two needs a shorter delay, not a longer chain.

This pairs with the same monitors that opened the incident in the first place — see uptime monitoring and heartbeat monitoring for how those checks get created; an escalation policy only ever matters once one of them has already opened an incident.

A Minimal Setup, Written Out

1. Set your own quiet hours to match when you actually sleep, with bypass set to urgent so a real incident still reaches you, but a routine deploy notification doesn't.
2. Create a two-step escalation policy on your production monitors: yourself at delay 0, a shared conversation at delay 10–15 minutes.
3. Attach that policy to the monitors that actually matter — not every monitor needs one; a low-stakes internal tool going down at 3am can reasonably wait until morning with no escalation at all.
4. Acknowledge every incident you see, even if you're already fixing it and even if it's a false alarm. Acknowledging is what stops the chain — a fix with no acknowledgment still pages the next person.

This is a smaller version of the same practice covered in incident response for solo developers, focused specifically on the two settings — quiet hours and escalation — that decide whether an alert reaches a human at all before anyone gets to the acknowledge-and-resolve part of that process. And once an incident is open and escalating, a linked status page is the separate question of what your users are told while it's being worked.

Frequently Asked Questions

Does Pingwire support on-call rotations?
No. Escalation policies are a fixed, ordered chain of specific targets — not a rotating schedule. For a team of one or two, a fixed chain is usually sufficient; a calendar-based rotation is a different category of tool.

What happens if I never acknowledge an incident?
The chain keeps firing every remaining step on schedule. If a policy has repeat_last enabled, the final step repeats rather than going silent once the list is exhausted.

Can quiet hours block an urgent incident entirely?
Yes, if you set your bypass level to never — that's an explicit choice, not a bug. The default bypass is urgent, so urgent-priority alerts reach you regardless of the hour unless you've deliberately turned that off.

Do quiet hours apply to every step in an escalation chain, or just to me?
Each step's target has their own quiet hours setting, evaluated independently. Your quiet window doesn't silence the next person in the chain, and theirs doesn't silence you.

How is escalation timing calculated if a check was delayed?
From the incident's original open time plus each step's cumulative delay — not from "now" at the moment a step fires. That way a brief outage in the checking process itself doesn't push every escalation deadline later; overdue steps fire as soon as it's back.

Do I need an escalation policy on every monitor?
No. Attach one to monitors where a missed alert is actually costly — production, payments, anything customer-facing. A monitor on a low-stakes internal tool can reasonably have no escalation policy at all and just wait for you to see it.