Zero Friction PagerDuty Alert Dashboard for 3 AM

A zero-friction PagerDuty alert dashboard for 3 AM is a single screen that lets an on-call engineer see what is broken, how bad it is, and what to do first — without clicking, scrolling, or interpreting charts. You design it around the alert’s severity, the service’s runbook link, and a one-glance status summary, so the engineer can act within seconds of waking up.

Formula

The calculator above estimates a “friction score” for an incoming alert — a rough number that tells you how much cognitive load that alert will impose at 3 AM. The formula is:

Friction Score = (Severity × 20) + min(Alert Age / 5, 20) + (15 if no runbook link)

Where:

• Severity — your PagerDuty severity level (1 = low, 5 = critical). Higher severity forces more immediate attention.
• Alert Age — minutes since the alert first fired. Older alerts may have been handled or may indicate a stuck incident.
• Runbook Link — whether the alert payload includes a direct link to a runbook (1 = yes, 0 = no). Missing runbooks force the engineer to search.

The score ranges from 0 (trivial) to 100 (worst possible). The formula is a heuristic, not a scientific measure — it’s meant to help you compare alerts quickly, not to replace your judgment.

Worked Example

Using the defaults from the calculator: alert age = 15 minutes, severity = 4, runbook link = yes.

1. Severity component: 4 × 20 = 80
2. Age component: min(15 / 5, 20) = min(3, 20) = 3
3. Runbook component: (1 – 1) × 15 = 0
4. Total: 80 + 3 + 0 = 83

The suggested priority is max(1, min(5, ceil(4/2) + (15 > 30 ? 1 : 0))) = max(1, min(5, 2 + 0)) = 2. So a severity-4 alert with a runbook link and 15 minutes old gets a friction score of 83 and a priority of 2 (moderate).

Why 3 AM Changes Everything

At 3 AM, your brain is running on a fraction of its normal capacity. The dashboard that works fine at 2 PM — with dense graphs, multiple columns, and hover tooltips — becomes a cognitive obstacle course at 3 AM. The goal is to reduce the number of decisions the engineer has to make before they can act.

Key principles:

• One screen, no scrolling: The entire alert summary must fit on a single viewport. If you have to scroll to see the severity, that’s friction.
• Color is the first language: Use red for critical, yellow for warning, green for resolved. Don’t rely on text alone.
• Actionable links first: The runbook, the service dashboard, and the incident timeline should be the first three links on the page — not buried at the bottom.
• Suppress the noise: If an alert has been auto-acknowledged or is a known duplicate, show that prominently. Don’t make the engineer figure it out.

Core Components of the Dashboard

Based on how incident response teams actually work, a zero-friction dashboard typically has these sections:

• Current incident banner: Shows the alert title, severity, service name, and time since first triggered. Big text, high contrast.
• Runbook shortcut: A single button that opens the runbook in a new tab. If no runbook exists, show a warning icon.
• Affected services list: Which services are down or degraded, with a green/yellow/red status dot.
• Recent activity timeline: Last 10 events from PagerDuty (acknowledged, escalated, resolved, new notes).
• Quick actions: Buttons for “Acknowledge”, “Resolve”, “Add note”, and “Escalate” that work with one click — no confirmation dialogs.
• Dependency map (optional): A simple diagram showing which services depend on the failing one, so the engineer can gauge blast radius.

How to Build It (Practical Steps)

You don’t need a custom app. Most teams build this as a simple web page that pulls from the PagerDuty API. Here’s the typical approach:

1. Fetch incidents from PagerDuty API: Use the GET /incidents endpoint with a filter for status=triggered or acknowledged. Poll every 30 seconds.
2. Sort by urgency: Sort by severity (descending), then by age (oldest first). The most critical, longest-running alert goes on top.
3. Render a single-card layout: For each incident, show severity, title, service, age, and links. Use a CSS grid that stacks on mobile.
4. Add a global status bar: At the top, show a summary like “3 critical, 2 warning, 1 resolved” — the engineer can see the whole picture at a glance.
5. Implement one-click actions: Use the PagerDuty REST API to acknowledge or resolve an incident directly from the dashboard. No confirmation dialog.
6. Serve it over HTTPS: You’ll be logging in from a phone or laptop at 3 AM — make sure it loads fast and works offline with a service worker if possible.

Common Mistakes and How to Avoid Them

Even well-intentioned dashboards fail at 3 AM. Here are the most common pitfalls:

• Too many metrics: Showing CPU usage, error rates, and latency for every service creates information overload. Show only the metrics that directly indicate the incident’s impact.
• Missing runbook links: If the runbook isn’t in the alert payload, the engineer has to search a wiki — that’s minutes of friction. Enforce a policy that every alert must include a runbook URL.
• No mobile optimization: At 3 AM, the engineer is likely on a phone. A dashboard that requires a mouse or a wide screen is useless.
• Ignoring auto-resolution: If an alert auto-resolves after 10 minutes, but your dashboard still shows it as active, that’s confusing. Sync with PagerDuty’s status changes.

Comparing Options: Homegrown vs. Existing Tools

You have two main paths:

• Build your own: Full control, but requires development time and ongoing maintenance. Best for teams with specific workflows or complex dependencies.
• Use PagerDuty’s built-in dashboard: PagerDuty offers a “Service Directory” and “Incident Workbench” that already show active incidents. It’s decent, but not zero-friction — you still have to click into each incident to see runbooks and actions.
• Third-party incident management tools: Tools like FireHydrant or Incident.io integrate with PagerDuty and provide a more streamlined incident response view. They cost extra but save engineering time.

For most teams, starting with PagerDuty’s own UI and adding a custom single-page dashboard that links out to it is a good balance.

Costs and Maintenance

Building a custom dashboard costs engineering time — roughly 2-5 days for a simple version, depending on your stack. Hosting is trivial (a static page on S3 or Netlify, or a small server). The ongoing cost is maintaining the integration as PagerDuty’s API changes (rare) and as your services evolve (more common).

Alternatively, using a third-party tool adds a per-seat subscription cost. Weigh that against the time your on-call engineers spend fumbling with the default UI. If you have more than 5 on-call rotations per month, the custom dashboard often pays for itself in reduced mean-time-to-acknowledge (MTTA).

Safety and Accuracy Notes

This dashboard is a tool for incident response, not a substitute for judgment. Always ensure that:

• You have a clear escalation policy — the dashboard should never be the only way to reach an on-call engineer.
• Runbooks are reviewed and updated regularly — a stale runbook is worse than none.
• Access to the dashboard is protected — it shows sensitive incident data.
• The dashboard’s status is accurate — test it with simulated incidents to avoid false confidence.

Frequently Asked Questions

Q: Can I use PagerDuty’s own API to build this without paying extra?
Yes, the PagerDuty API is included in all plans. You can fetch incidents, acknowledge, resolve, and add notes. The dashboard itself is just a frontend that calls those endpoints.

Q: How do I make the dashboard work on a phone?
Use a responsive CSS framework (like Bootstrap) or a mobile-first design. Test on actual phones — not just the browser’s dev tools. Ensure buttons are large enough to tap with a thumb.

Q: What if my team uses Slack instead of PagerDuty?
Slack has similar alerting features, but the API is different. You can build a similar dashboard using Slack’s API, but you’ll lose some PagerDuty-specific features like on-call schedules and escalation policies.

Q: How do I handle false alerts?
Implement a “mute” or “snooze” feature in your dashboard that suppresses an alert for a set time. Also, review alert thresholds regularly to reduce noise — the best dashboard is one that shows nothing.

Q: Is it worth building a custom dashboard vs. buying an incident management tool?
It depends on your team size and budget. For small teams (under 10), a custom dashboard is often cheaper. For larger teams, a dedicated tool may offer better analytics and integrations out of the box.

Related

• Noise Canceling vs Noise Isolating: Which Is Better?
• Why Avoid Phones with Razor-Thin Bezels?
• Linux Distros Beginners Should Avoid

in t | Alert age (min) | min | 15 | 0 | 1440
in s | Severity (1=low, 5=critical) | - | 4 | 1 | 5
in r | Runbook link present (1=yes, 0=no) | - | 1 | 0 | 1
out score | Friction score | 0-100 | (s * 20) + min(t / 5, 20) + ((1 - r) * 15) | 0
out priority | Suggested priority | - | max(1, min(5, ceil(s / 2) + (t > 30 ? 1 : 0))) | 0
out age_note | Age note | - | t > 60 ? "Over 1 hour old — check for duplicates" : "Fresh alert" | 0