Back to blog
1 min read
On-callGuide

Should staging share production's on-call?

Staging pages at 2am train people to hate the pager. Keep staging noisy in daylight, and keep production pages sacred.

NK

Nabin Khair

Founder

Staging breaks constantly. That is partly the point. If those breaks climb the same ladder as production login failures, on-call will mute everything, including the real ones.

Default recommendation

  • Production → on-call, escalation, night pages for customer impact.
  • Staging / preview / QA → Slack or email, business hours, no secondary escalation.

Same monitoring product is fine. Same escalation policy is not.

When staging might page

  • Staging is customer-facing (rare, but some B2B demos live there).
  • A shared database means staging risk is production risk. Fix that architecture; do not paper over it with pages.
  • Release trains that block on staging health overnight with a willing owner

Even then: separate policy, clearer name on the alert ("STAGING"), and no level-3 manager climb.

Hygiene

Label monitors clearly. Route by policy, not by hoping humans read the URL. After false night pages from staging, demote immediately. Do not "remind the team to ignore those."

Production pages should feel rare and sharp (page vs notify). Staging noise belongs in the day job. Mixing them is how you burn the only resource that matters: attention at 3am.

Keep reading

More from the Tallwatch blog

More on monitoring, alerting, and status pages.