Paging Philosophy

Ticket versus page decisions, urgency thresholds, escalation paths, and sleep-impact tradeoffs.

6 min readSRE PlaybookOperate

Page or Ticket?

Every alert must be classified as either a page (immediate human action) or a ticket (scheduled work). Pages interrupt lives. Tickets wait in a queue. The classification must be based on user impact, not internal urgency.

Page vs ticket decision matrix


decision_matrix:
  page_when:
    - "Users are currently experiencing errors"
    - "Data loss is occurring or imminent"
    - "Security breach is confirmed"
    - "Service is completely unavailable"
    - "SLO will be breached within 1 hour if no action"

  ticket_when:
    - "Errors are below user-impacting threshold"
    - "Degradation is minor or intermittent"
    - "Issue can wait until business hours"
    - "No user-facing impact"
    - "SLO breach is not imminent"

  example_alerts:
    page:
      - alert: "Error rate > 10% for 5 minutes"
        reason: "Users seeing errors now"

      - alert: "Disk full on database server"
        reason: "Database will stop accepting writes"

      - alert: "Certificate expired"
        reason: "Service returning TLS errors"

    ticket:
      - alert: "Error rate > 1% for 30 minutes"
        reason: "Below user-impacting threshold"

      - alert: "Disk usage > 85%"
        reason: "Hours before impact"

      - alert: "Certificate expires in 14 days"
        reason: "Can be handled during business hours"

Urgency Thresholds

Define urgency thresholds for each type of alert. Use time-based thresholds: how soon will users be impacted? How soon will the SLO be breached? How soon will data be lost?

Urgency threshold definitions


urgency_thresholds:
  immediate_0_minutes:
    classification: "Page"
    examples:
      - "Complete service outage"
      - "Data corruption detected"
      - "Security breach confirmed"
    response: "Respond within 5 minutes"

  soon_15_minutes:
    classification: "Page"
    examples:
      - "Error rate > 20% and rising"
      - "Disk full, writes failing"
      - "Database replica lag > 1 hour"
    response: "Respond within 15 minutes"

  eventually_1_hour:
    classification: "Page or Ticket"
    examples:
      - "Error rate > 5% for 10 minutes"
      - "Latency p99 > 2s for 15 minutes"
      - "Disk usage > 90%"
    response: "Respond within 1 hour"

  someday_24_hours:
    classification: "Ticket"
    examples:
      - "Certificate expires in 14 days"
      - "Disk usage > 80%"
      - "Performance degradation below SLO"
    response: "Respond within 24 hours"

Sleep Impact

Every page during sleeping hours has a real impact on the engineer's health. Consider sleep impact when deciding whether to page. If the issue can wait until morning without user impact, it should be a ticket.

Sleep impact guidelines


sleep_impact:
  no_impact:
    time: "Business hours (9 AM - 5 PM local)"
    classification: "Page normally"

  moderate_impact:
    time: "Evening (5 PM - 10 PM local)"
    classification: "Page only if user impact is significant"
    examples:
      - "Error rate > 20% for 10 minutes"
      - "Complete service outage"

  high_impact:
    time: "Night (10 PM - 7 AM local)"
    classification: "Page only if users are currently impacted"
    examples:
      - "Error rate > 50% for 5 minutes"
      - "Data loss occurring"
    mitigation:
      - "Ensure secondary on-call is available"
      - "Provide next-day recovery time"

  consideration:
    - "Can the issue wait until morning?"
    - "Are users currently affected?"
    - "Will waiting make the problem worse?"
    - "Is there a secondary responder available?"

Escalation Paths

Define clear escalation paths for different alert types. Escalation ensures that if the primary responder cannot handle the issue, someone else will. Escalation should be automatic, not manual.

Escalation path configuration


escalation_paths:
  standard_alert:
    level_1:
      target: "On-call engineer"
      wait: 0
      notification: ["PagerDuty", "Slack"]

    level_2:
      target: "Secondary on-call"
      wait: 10m
      notification: ["PagerDuty", "SMS"]

    level_3:
      target: "SRE manager"
      wait: 20m
      notification: ["PagerDuty", "Phone"]

  critical_alert:
    level_1:
      target: "On-call engineer + Secondary"
      wait: 0
      notification: ["PagerDuty", "Slack"]

    level_2:
      target: "SRE manager + Team lead"
      wait: 5m
      notification: ["PagerDuty", "Phone"]

    level_3:
      target: "VP Engineering"
      wait: 15m
      notification: ["PagerDuty", "Phone"]

Core Paging Principles

Page only on user-impacting symptoms — never on causes.
Every page must be actionable — if no action is needed, do not page.
Pages interrupt lives — treat them as sacred.
Pages must link to runbooks — no page without a documented response.
Pages must have clear ownership — every page goes to someone specific.
Pages must be tuned regularly — noisy pages cause fatigue.

Paging Review Process

Review your paging policy monthly. Analyze page volume, response times, false positive rates, and sleep impact. Use this data to tune thresholds, delete non-actionable alerts, and improve response times.

Monthly paging review


monthly_paging_review:
  metrics:
    - name: "Total pages"
      target: "Decreasing trend"
      action: "Investigate if increasing"

    - name: "Pages per engineer"
      target: "< 10 per week"
      action: "Redistribute if uneven"

    - name: "Night pages (10 PM - 7 AM)"
      target: "< 20% of total"
      action: "Review thresholds if high"

    - name: "False positive rate"
      target: "< 10%"
      action: "Tune or delete noisy alerts"

    - name: "Mean time to acknowledge"
      target: "< 5 minutes"
      action: "Check schedule accuracy if high"

  actions:
    - "Delete non-actionable alerts"
    - "Adjust thresholds to reduce noise"
    - "Update runbooks for frequently-fired alerts"
    - "Verify escalation policies are current"
    - "Rebalance on-call rotation if uneven"

Pages are a cost, not a feature

More pages do not mean more reliability. They mean more interrupted lives, more fatigue, and more ignored alerts. Reduce page volume by improving reliability, not by lowering alert thresholds.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.

Stage 6 · Operate

Alerting Hygiene & Paging Design