The Analog Incident Story Lighthouse: Hand‑Built Paper Beacons for Foggy Outages

When an outage hits, it rarely feels like a clean, linear story.

It feels like fog.

Slack scrolls by too fast to follow. Dashboards compete for attention. Everyone is talking, few people are actually aligned, and the incident “story” lives in a dozen tools at once. People get tired, context gets lost, and decisions start to fray.

This is where an Analog Incident Story Lighthouse comes in.

A lighthouse is a physical, hand‑built paper beacon that sits in the room (or in view of the camera) during an incident. It doesn’t replace your digital tools; it anchors them. It turns a chaotic, foggy event into a visible shared narrative the entire team can literally point at.

In this post, we’ll explore how to build and use these paper lighthouses to guide teams through incidents, improve on‑call experiences, and create better material for long‑term learning.

Why Analog Tools Matter in Digital Incidents

In theory, we already have everything we need:

Slack incident channels
Issue trackers
Status pages
Dashboards and traces
Runbooks and playbooks

In practice, during a stressful incident, digital tools can actually increase cognitive load:

Context is fragmented across tabs and channels.
Timelines are implicit, not visible.
Ownership and responsibilities are unclear.
People hesitate to ask “Wait, what’s going on?”

High pressure plus high complexity is a bad combo.

Analog tools—paper, markers, sticky notes, tape—work precisely because they are simple and human‑scale. They:

Force focus on only the most important information.
Are always in view, without scrolling or window‑switching.
Make abstract concepts (like “who’s doing what?”) concrete.
Encourage shared understanding instead of silent assumptions.

The lighthouse doesn’t compete with your digital stack; it helps your brain navigate it.

What Is an Incident Story Lighthouse?

An Incident Story Lighthouse is a large, hand‑built paper artifact that lives in the incident room (or on a wall in your war room). Its job is to:

Make the timeline of events visible.
Clarify roles and responsibilities.
Capture key decisions and their rationale.
Track current hypotheses, actions, and status.
Provide a single, shared reference point for the whole team.

Think of it as a visual, analog, real‑time story of the incident.

It might be as simple as:

A sheet of flip‑chart paper taped to a wall
A whiteboard section clearly labeled for the incident
A virtual whiteboard (Miro, FigJam, etc.), used as if it were physical

The key is that it is deliberate, visible, and actively maintained by someone in a defined role.

The Core Elements of a Lighthouse

You don’t need fancy design. You just need clear structure. A good lighthouse usually has these sections, drawn with thick markers:

1. Incident Header

At the top of the page:

Incident name / ID
Start time (with timezone)
Incident commander
Scribe (person maintaining the lighthouse)

This sets the frame: We are in an incident. This is it.

2. Visible Roles & People

A small box listing who’s doing what:

IC (Incident Commander): Name
Comms: Name
Tech Lead(s): Names
On‑call / Responders: Names or teams

When roles change, cross them out and write the new person. This makes ownership transitions explicit and reduces confusion.

3. Simple, Linear Timeline

Down one side of the paper, draw a vertical line. Add timestamps as the incident unfolds:

14:07 – Alert triggered: high error rate on API
14:10 – IC declared, Slack #inc‑1234 created
14:18 – Rolled back to previous release
14:24 – Customer impact confirmed: EU users only

This timeline isn’t exhaustive; it’s the spine of the story.

4. Current Situation & Hypotheses

A box labeled “Now” or “Current State”:

What we know is happening
What we think is happening (hypotheses)
Uncertainties and open questions

Example:

Symptoms: 5xx on /checkout for 30% of EU traffic
Hypothesis: new rate‑limiting config in edge proxy
Unknowns: impact on mobile vs. web, only EU?

5. Actions & Decisions

Separate from the timeline, a space for key actions and decisions, ideally on sticky notes that you can move:

“Rolled back release 2026.02.20.1”
“Disabled feature flag new_checkout_flow”
“Engaged database team”

Each should have:

A short label
A time
Who initiated it

These become anchors in both the live coordination and later review.

6. Status & Next Steps

A clearly labeled “Next 10–15 minutes” section:

What we’re actively doing now
What we’re waiting on (tests, metrics, responses)
The next check‑in time

This keeps the team moving in short, intentional cycles instead of wandering.

How to Use the Lighthouse During an Incident

Assign a Scribe

The incident commander should not draw. They should delegate the lighthouse to a scribe, whose responsibilities include:

Updating the timeline
Recording decisions and actions
Keeping “current state” honest and up to date
Surfacing confusion: “We have three competing hypotheses; which are we pursuing?”

Refer to It Out Loud

Make it a ritual:

“Let’s check the lighthouse: what’s our current hypothesis?”
“According to the timeline, when did we see the first error spike?”
“Before we add a new action, are we closing out the last one?”

Speaking to the lighthouse normalizes shared reality checks instead of relying on hazy memory under stress.

Keep It Ruthlessly Simple

If your lighthouse starts to look like a dense notebook, you’ve gone too far. A few guardrails:

Big handwriting, minimal text
Only important timestamps
Only key decisions, not every keystroke
No jargon that someone outside the team couldn’t understand later

The goal is clarity under pressure, not completeness.

Pairing the Lighthouse with a Practical Runbook

An analog lighthouse works best when paired with a short, practical runbook that matches its structure.

Your runbook should be:

Short: ideally 1–3 pages
Scannable: clear headings, bullets, checklists
Located: everyone knows where it lives

Suggested sections:

When to Declare an Incident
- Criteria (SLOs, alerts, customer reports)
- Who can declare
First 5 Minutes Checklist
- Declare IC
- Create incident channel
- Start the lighthouse
- Set rough severity level
Roles & Responsibilities
- IC: decide, coordinate, manage time
- Scribe: maintain lighthouse, capture decisions
- Comms: updates to stakeholders, status page
15-Minute Rhythm
- Review lighthouse: timeline, hypotheses, actions
- Decide next focus
- Confirm owners for actions
- Set next check‑in time
Closure & Handover
- Confirm mitigation or resolution
- Capture final state on lighthouse
- Take photos / export for post‑incident review

The runbook tells you what to do; the lighthouse shows what is actually happening.

How Analog Lighthouses Improve On‑Call Life

Lower Cognitive Load = Faster, Better Decisions

By offloading who, what, when, why to a physical artifact, responders free up mental bandwidth to think about the system, not the process.

They don’t have to remember:

Who’s in charge
What we tried already
When the rollback started
Whether someone already checked X

It’s on the wall.

Better Coordination, Less Cross‑Talk

A lighthouse encourages coordination patterns like:

“Add that to the lighthouse before we forget.”
“We already tried that at 14:22; see here.”
“We have three active actions; let’s not add a fourth yet.”

This reduces duplicate work, channel noise, and “hero mode” behavior.

Reduced Burnout Through Shared Understanding

Stress goes down when:

People see what’s happening
Roles are clear
There’s a visible plan, even if it changes

Instead of feeling like you’re drowning in Slack, you’re part of a team working around a shared map. That alone can make on‑call feel more humane.

Turning the Lighthouse Into Long‑Term Learning

When the incident is over, the lighthouse becomes raw material for learning.

Before you erase or recycle:

Photograph it from multiple angles.
Export or redraw key elements into your post‑incident document:
- Timeline
- Decisions and rationale
- Hypotheses that turned out wrong
Annotate it with what you learned:
- “We thought it was the DB, but it was DNS.”
- “We missed a whole region in our mental model.”

This makes your post‑incident review less about blame (“Who broke it?”) and more about story and discovery (“How did our understanding evolve over time?”).

Over time, patterns emerge:

Repeated confusion about ownership
Repeated blind spots in observability
Repeated delays in decision‑making

These insights feed back into:

Better tooling
Better documentation
Better training and onboarding

All starting from a sheet of paper on the wall.

Getting Started: A Lightweight Pilot

You don’t need an organizational mandate to try this. You can start small:

Put a pad of large paper and markers in your incident room (or near your desk).
For the next incident, explicitly assign a scribe.
Draw a simple lighthouse: header, roles, timeline, actions.
Use it for one incident, then:
- Ask the team what helped
- Capture a photo for the post‑incident review
- Tweak the layout for next time

If your team is remote, use a shared virtual whiteboard but treat it like physical paper: big text, simple structure, one screen everyone sees.

Conclusion: Build Your Own Beacons

Incidents will always be foggy. Systems are complex, conditions are stressful, and no set of tools will make outages feel “easy.”

But you can make them more navigable.

A hand‑built, analog Incident Story Lighthouse doesn’t try to out‑automate your incident management platform. Instead, it offers a human‑scale anchor: a visible story of who did what, when, and why that everyone can share.

By combining:

Simple physical tools (paper, markers, sticky notes)
A lightweight, checklist‑driven runbook
A ritual of maintaining and referring to the lighthouse

…you create a more coordinated, less draining, and ultimately more learning‑rich incident practice.

You don’t need permission to start. Grab some paper. Draw the first lighthouse. See how much clearer the fog feels when there’s a beacon in the room.