The Analog Incident Story Solar System Shelf: Orbiting Paper Planets of Failure Around Your Team’s Daily Work

Digital incident tools are powerful—but they’re also easy to ignore.

Dashboards sit in browser tabs no one opens. Postmortem docs get filed away. Metrics drift into the background noise. Meanwhile, the same types of failures quietly reappear because they’re out of sight and out of mind.

What if your team’s incidents weren’t hidden in Confluence or a status page, but hanging right next to your desks—moving around like a little galaxy you work inside every day?

That’s the idea behind the Analog Incident Story Solar System Shelf: a physical, visual installation that turns your incident history into orbiting paper planets your team literally works around.

In this post, you’ll learn how to build one, what to put on each “planet,” and how to use it as a practical tool for learning, not just decoration.

Why Go Analog for Incidents?

Incidents are messy, human, and story-driven. They’re not just numbers in a dashboard; they’re events that shaped your systems, your users’ experience, and your team’s thinking.

An analog, tangible metaphor—like a small solar system of failures—works because:

It’s constantly visible in your physical space.
It invites curiosity and conversation (“What’s that red planet about?”).
It normalizes failure as part of the landscape, not a hidden shame.
It makes abstract risk and resilience concrete and shared.

By pulling incidents out of purely digital tools and onto a wall, shelf, or hanging mobile, you create a living memory of what your team has gone through and what you’ve learned.

Step 1: Build Your Solar System Shelf

You don’t need an interior designer. You need cardboard, markers, tape, and a bit of imagination.

Pick your physical format:

A floating shelf on the wall with different “orbits” marked by concentric circles.
A pinboard or whiteboard with rings drawn around a central “sun.”
A hanging mobile with paper planets on strings.

At the center, place your “sun”—this represents your current core system or product. Everything that has gone wrong or could go wrong orbits around it.

Then, mark out orbits: rings or levels where planets can be placed. These distances will carry meaning.

Step 2: Turn Incidents into Planets

Each past incident becomes its own planet.

Cut circles from colored paper or cardboard. Each planet should be:

Named (give it a short, memorable incident name).
Labeled with key data.
Sized or styled to stand out based on importance.

On the front of each planet, write:

Name: A human-readable title (e.g., The Tuesday Timeout, The Great Cache Meltdown).
What Failed: Short description of the broken component or behavior.
Impact: Who or what was affected (users, internal teams, revenue, reputation).
Contributing Factors: A few bullets capturing the main contributing conditions.
Recovery Path: How you detected, mitigated, and restored service.

You can let the planet color signal a theme:

Red: User-visible outages.
Blue: Performance and latency issues.
Green: Data integrity or consistency problems.
Yellow: Security or access-related incidents.

Now your incidents aren’t just ticket IDs; they’re visual, storied objects.

Step 3: Use Orbits to Show Severity, Frequency, or Proximity

The magic of a solar system metaphor is distance.

Position planets at different orbits to signal concepts that matter to you. Pick one primary meaning for distance so it’s easy to read at a glance. For example:

Option A: Orbit = Severity

Inner orbits: High-severity incidents with major user or business impact.
Middle orbits: Medium severity or partial degradation.
Outer orbits: Low-severity issues or incidents with small blast radius.

Option B: Orbit = Frequency / Recurrence

Inner orbits: Incident patterns that recur or relate to ongoing weak spots.
Outer orbits: Rare or one-off events.

Option C: Orbit = Closeness to Current Work

Inner orbits: Risks and incidents tied to current projects, active migrations, or hot paths.
Outer orbits: Older or less relevant incidents further removed from today’s roadmap.

You can even combine a couple of signals:

Distance from the sun = relevance to current work.
Planet size = impact or severity.

This makes the shelf a visual risk map your team sees every day.

Step 4: Make It a Living System, Not a Museum

The shelf should change as your system and work change.

Treat it like a living ecosystem:

Add new planets after every incident review.
Move planets as risks get closer or farther from current projects.
Retire or archive planets when patterns are resolved or systems are decommissioned.

Some rituals to keep it alive:

Monthly orbit review: Once a month, spend 15 minutes moving planets closer or farther:
- Did this risk surface again? Move it inward.
- Did we ship structural fixes? Push it outward.
Pattern retirement: When a recurring pattern has gone, say, 6–12 months without reappearing and you’ve changed architecture or processes to address it, ceremonially move the planet to an “outer archive ring” or a separate section labeled Extinct Stars.

These small actions signal that risk is dynamic, and so is your learning.

Step 5: Bring Conversations Into the Solar System

The solar system shelf is not just art. It’s a prompt for discussion.

Use it in your existing rituals:

Standups:

Ask, “Which planets are close to the work we’re doing this week?”
Briefly point to 1–2 relevant incidents when discussing risky changes.

Retrospectives:

Start retros with a quick scan: “Did anything this sprint bring us closer to these inner-orbit planets?”
Use planets as story anchors: “We almost recreated The Great Cache Meltdown. Why?”

Incident Reviews / Postmortems:

After an incident review, the final step is: create the planet.
Have the incident lead tell the story while physically placing the planet in orbit.

By literally standing in front of the solar system, you shift incident discussions out of abstract slides and into a shared, physical context.

Step 6: Mix Story with Simple Data

Pure narrative makes incidents memorable. Pure metrics help spot patterns. You need both.

On each planet, pair qualitative narrative with a few simple quantitative markers:

Qualitative:

A 1–2 sentence story of what happened.
What surprised the team.
One key lesson or “design principle” that came out of it.

Quantitative (small icons, numbers, or shorthand):

TTD (Time To Detect) – e.g., TTD: 45 min.
TTR (Time To Restore) – e.g., TTR: 3h 20m.
Blast Radius – number of users impacted, or services affected.

You can add small symbols:

⏱ next to time-based metrics.
🌐 for user impact scope.
🧩 for number of components involved (complexity).

Keeping metrics simple and consistent helps teams see, for example:

“All our inner planets have long TTD—detection is our weak spot.”
“We restore quickly, but blast radius is large. We need better isolation.”

The shelf becomes a visual analytics board, but without the need to open a tab.

Step 7: Design for Psychological Safety and Resilience

Most importantly, design your solar system to normalize failure, not weaponize it.

Some principles:

No names of individuals. Planets are about systems, processes, and conditions—not blame.
Highlight learning, not fault. Every planet should include a “What we changed” or “Key lesson” note.
Celebrate improvement. When a planet moves outward or gets archived, mark the moment.

You can even add “resilience satellites”—small paper moons around planets representing:

New alerts.
New runbooks.
Architectural changes.
Experiments that increased robustness.

This visually reinforces that incidents are inputs to improvement, not failures to hide.

Putting It All Together

By building an Analog Incident Story Solar System Shelf, you:

Turn intangible risk into tangible, shared context.
Make past failures present in daily work—without heavy process.
Encourage storytelling grounded in data, not just stats or just anecdotes.
Normalize incident discussion as a normal, expected part of engineering, not an exception.

You don’t need perfect aesthetic execution. A slightly wonky cardboard solar system is often better: it feels approachable and invites contributions.

What matters is that your team can look up from their laptops and see:

Where you’ve been (planets of past failures).
What you’ve learned (lessons and moons of resilience).
What’s close to your current work (inner orbits).

That constant, quiet visibility nudges your culture toward experimentation, openness, and resilience.

If your incident learning feels stuck in documents no one reads, try giving your failures a place in your physical universe. Build a shelf. Cut some paper. Let your incidents orbit where everyone can see them—and let that visibility pull your team toward better systems, together.