Paging Load by Day-of-Week

Pages cluster by day. Patterns.

Pages cluster by day

Most production stacks page hardest Tuesday through Thursday during business hours, with secondary peaks on deploy days. Weekends and holidays have fewer pages but higher-severity ones because no humans are around to catch problems early. Plotting pages by day-of-week and hour-of-day reveals the real on-call shape.

• Tuesday-Thursday business-hours peak. Most production stacks page hardest in this window.
• Deploy-day secondary peaks. Pages cluster around deploy timing; the cause is usually the deploy itself.
• Weekend severity. Fewer pages but higher severity because no humans catch problems early.
• Per-team paging shape. Plot by day-of-week and hour-of-day; the pattern is the real on-call shape.

Rotations should match the pattern

If 80% of pages happen Tuesday-Thursday 9am-6pm, a 24/7 follow-the-sun rotation is wasteful. Split rotation works: business-hours primary in the right time zone, off-hours fallback rotation. Off-hours rotation deserves compensation because off-hours pages are 5-10x more painful per page.

• 24/7 follow-the-sun is wasteful. If 80% of pages happen Tuesday-Thursday 9am-6pm, the rotation should match.
• Split rotation. Business-hours primary in the right time zone; off-hours fallback rotation.
• Off-hours compensation. Off-hours pages are 5-10x more painful per page; pay for the pain.
• Per-rotation match-to-shape. Rotation structure follows the paging shape, not corporate convention.

Deploy days create their own load

Friday deploys page on Saturday. Don’t ban Friday deploys; instead, page the deployer first and the on-call second. Tag deploys in the alerting tool so deploy-followed-by-alert routes back to the deployer; deploy-induced page rate above 20% means CI is missing regressions.

• Friday deploys page Saturday. Deploy-induced incidents arrive after the deployer has logged off.
• Page the deployer first. Route alerts that follow a deploy by under 30 minutes to the deployer, not the on-call.
• Tag deploys. Alerting tool tags deploys; correlation routing becomes automatic.
• Track deploy-induced rate. Above 20% of pages tied to recent deploys means CI is missing regressions.

Seasonal load

Seasonal load is predictable. E-commerce: Black Friday week; tax software: April; banking: end of month and end of year. The discipline is to surge rotations during predicted peaks and mute non-critical alerts so tuning is for high-severity catches only.

• Predictable seasonal peaks. E-commerce Black Friday week, tax software April, banking end-of-month.
• Surge rotations. Add a second on-call for the peak window only; the burden is shared.
• Mute non-critical alerts. Tune for high-severity catches during peak; reduce noise to keep focus.
• Per-season runbook. Documented surge plan per peak; supports preparation, not improvisation.

How to use the data

The data drives the action. Pull 6 months of paging data, plot by day-of-week, hour-of-day, and day-of-month; reshape rotations to match the actual shape (bigger primary Tuesday-Thursday, smaller fallback on weekends); re-evaluate every 6 months because the pattern shifts with the product.

• Pull 6 months of data. Plot by day-of-week, hour-of-day, day-of-month; the multi-axis view exposes the shape.
• Reshape rotations. Bigger primary on Tuesday-Thursday, smaller fallback on weekends; rotation matches reality.
• Re-evaluate every 6 months. The pattern shifts with the product; the rotation must follow.
• Per-evaluation deliverable. A documented rotation update per cycle; supports continuous fit.