Oncall shift should be Tuesday to Tuesday

On‑call rotations for software and IT teams are being rethought, with many engineers favoring mid‑week handovers (e.g., Tuesday‑to‑Tuesday or Thursday‑to‑Thursday) to avoid ruined weekends, awkward Monday transitions, and holiday clashes. Commenters compare alternative patterns — split day/night shifts, follow‑the‑sun global coverage, shorter rotations, or outsourcing to managed service providers — and emphasize that sustainable schedules must be paired with clear handoff practices and strong incident follow‑up. A major fault line runs over compensation and boundaries: some see paid, tightly regulated on‑call as a necessary cost of high availability, while others reject unpaid or poorly managed pager duty outright as unhealthy and exploitative.

On‑call shift timing (Tuesday–Tuesday vs others)

  • Many agree mid‑week handoffs (Tue–Tue, Wed–Wed, Thu–Thu) avoid Monday chaos, Friday fatigue, and Monday holidays.
  • Some teams align on‑call and sprint cycles to Tuesdays and report happier devs and easier reporting for management.
  • Others prefer Mon–Mon for “clean” calendar weeks, or Fri–Fri to finish on Friday and recover over the weekend.
  • A few report shifting from Tue–Mon to Mon–Sun reduced stress because carrying on‑call into Monday after a hard weekend felt worst.

Alternative rotation patterns

  • Variants include: Fri‑night–Fri‑night; Thu–Thu with the following Friday off; split daytime vs nighttime on‑call; daily “follow‑the‑sun”; 4/3 splits (weekdays vs weekend), and short 48‑hour primary/backup windows.
  • Some teams assign each person a fixed weekday plus a shared weekend rotation. Others use complex patterns to equalize paid days.
  • Opinions differ: shorter, more frequent shifts feel “more natural” to some but are criticized for too many handoffs and vacation complexity.

Compensation, labor law, and incentives

  • Wide range of pay: from nothing at all to substantial weekly stipends plus premium overtime or TOIL.
  • Several European commenters cite strong legal protections: mandatory rest periods, required standby pay, higher multipliers for nights/weekends, and explicit illegality of unpaid on‑call.
  • Debate over per‑page pay vs flat standby:
    • Critics warn per‑page rewards outages and noise.
    • Supporters say it exposes the true business cost, pressures management to fix recurring issues, and deters trivial pages.
  • Some argue on‑call should always be explicitly paid to align incentives; others see it as part of salaried expectations.

Attitudes toward on‑call itself

  • Many see on‑call as a “necessary evil” for genuinely critical systems; others think most web services over‑engineer availability.
  • Strong minority refuse any on‑call, citing health, family life, and prior burnout.
  • Others accept it in exchange for high compensation or influence over reliability work; some treat refusal to be on‑call as career‑limiting.

Operational practices and quality

  • Teams that review all pages weekly, classify good/bad alerts, and create runbooks/playbooks report major reductions in pager noise.
  • Multiple commenters emphasize that healthy on‑call requires:
    • authority and time to fix root causes,
    • realistic SLAs (not gratuitous “five nines”),
    • and, where possible, follow‑the‑sun coverage instead of waking people at 3 a.m.