Introduction

Most incident reviews end with the same regret: “The signals were there, we just didn’t line them up before launch.”

Teams usually have logs, tests, dashboards, and sign-off checklists. What they don’t have is a shared, visual picture of where a new feature is most likely to hurt them—and how badly.

Enter the Analog Incident Radar: a one-page, hand-drawable threat map you create before shipping risky features. It doesn’t replace formal threat modeling or security reviews. It’s the fast, pragmatic layer you add on top so everyone sees the same risk landscape at a glance.

This post walks through how to design, use, and maintain an Analog Incident Radar:

• What a one-page threat map looks like
• The five critical dimensions to map
• How to use it in product/engineering/security conversations
• How to connect it to mitigations and observability
• How to keep it a living artifact instead of a forgotten PDF

What Is an "Analog Incident Radar"?

Think of the Analog Incident Radar as a risk sketch for a specific feature or change:

• One page: It must fit on a single screen or sheet of paper.
• Visual first: Quadrants, axes, or a radar/spider chart—something people can grasp in 10 seconds.
• Collaborative: Built in conversation with product, engineering, and security.
• Tied to action: Every big risk has at least one concrete mitigation.

You’re not trying to capture every possible issue. You’re trying to highlight the few ways this feature could ruin your day and how you’ll contain the damage if it happens.

Use it:

• Before shipping a risky or user-facing feature
• Before big architecture changes or migrations
• Before toggling on a high-stakes experiment

If your launch has the power to break revenue, data integrity, or trust, it deserves an Analog Incident Radar.

Focus on a Few Critical Dimensions

A useful threat map is opinionated. Don’t track 20 things. Start with five core dimensions and adjust as needed:

1. Impact – How bad is it if this goes wrong?

   • Does it affect core revenue flows?
   • Does it risk data loss, corruption, or privacy issues?
   • Does it damage brand trust or compliance?

2. Likelihood – How likely is a failure or abuse?

   • Is this code path new or complex?
   • Does it rely on flaky dependencies or unproven assumptions?
   • Is it attractive for abuse (e.g., payments, auth, promotions)?

3. Detectability – How fast and clearly will we notice something’s wrong?

   • Do we have metrics, logs, and alerts that would surface the issue?
   • Can on-call humans see the problem without digging for hours?

4. Blast radius – How widely does the damage spread?

   • One user, one cohort, or the entire customer base?
   • One region or your whole infrastructure?

5. Recovery difficulty – How hard is it to unwind the damage?

   • Can we toggle a flag or rollback safely?
   • Do we need complex data repair or manual interventions?

For each major risk scenario, you quickly rate these dimensions—often with a simple 1–5 scale or by mapping them visually.

How to Sketch the One-Page Threat Map

You can use a whiteboard, a tablet, or a simple drawing tool. The key is fast and legible, not beautiful.

One simple format:

1. Start with a 2×2 or radar chart

Two common layouts:

• 2×2 grid

  • X-axis: Likelihood (low → high)
  • Y-axis: Impact (low → high)
  • Plot each risk as a dot. Use color/shape to indicate detectability or blast radius.

• Radar (spider) chart

  • Axes: Impact, Likelihood, Detectability (inverted), Blast Radius, Recovery Difficulty
  • Each risk is a polygon showing its profile across these dimensions.

For most teams, the 2×2 grid is enough and much faster to adopt.

2. Identify 5–10 realistic risk scenarios

Examples for a new billing feature:

• Double-charging customers
• Failing to charge at all
• Creating inconsistent invoice states
• Leaking partial payment data in logs
• Rate limiting blocking legitimate bulk operations

Avoid vague statements like “system instability.” Be concrete: “Checkout latency >3s for >20% of users in EU.”

3. Place each risk on the map

For each scenario, ask as a group:

• How bad is this if it happens? (Impact)
• How likely is it to happen in the first week? (Likelihood)
• How fast and clearly would we see it? (Detectability)
• How many users/systems would it affect? (Blast radius)
• How painful is the clean-up? (Recovery difficulty)

Plot the risk in your 2×2 by likelihood/impact, then annotate with:

• Icon or color for detectability (e.g., green = easy to detect, red = hard)
• Number or label for blast radius (e.g., 1 = few users, 3 = all users)

On the side of the page, add a small table:

This is your analog incident radar: at a glance, everyone sees where the big, ugly risks live.

Make Tradeoffs Explicit Across Teams

The real value of the threat map is conversation, not the artifact itself.

Bring product, engineering, and security together and walk through the map:

• Product can argue: “We can accept this risk for the first cohort of 5% of users, but not for all users.”
• Engineering can say: “To reduce likelihood here, we’d need another week for tests and load validation.”
• Security can insist: “This data leak risk is unacceptable without log scrubbing and tighter access controls.”

Use the map to answer:

• Which risks are show-stoppers vs. which are acceptable with guardrails?
• Where do we need stronger mitigations before launch vs. before 100% rollout?
• What level of observability and alerting do we require before enabling the feature?

By the end, the group should clearly document:

• Which risks we are accepting, and why
• Which we are reducing, and how
• Which are blocked, pending mitigations

This makes tradeoffs between speed and safety explicit and agreed, instead of fuzzy and assumed.

Connect Each Risk to Concrete Mitigations

Every risk in the high-impact/high-likelihood corner needs at least one mitigation. A simple rule:

No red-dot risk without a named mitigation and owner.

Common mitigation patterns include:

• Feature flags

  • Gradual rollout (1% → 10% → 50% → 100%)
  • Ability to instantly disable a risky pathway

• Rate limits and quotas

  • Prevent abuse and runaway processes
  • Protect underlying services (DB, third-party APIs)

• Rollbacks and safe deploy strategies

  • Blue/green or canary deployments
  • Pre-validated rollback paths for schema and config changes

• Extra tests

  • Targeted unit/integration tests for the most dangerous flows
  • Chaos or load tests around critical dependencies

• Additional monitoring and alerts

  • New metrics for error rates, latency, or behavior (e.g., refund spikes)
  • Synthetic checks for end-to-end flows

On the bottom of your one-pager, add a simple table that links risks to mitigations:

This ensures your threat map isn’t just a risk catalog; it’s a mitigation plan.

Tie the Radar Into Release and Observability

Your Analog Incident Radar becomes really powerful when it hooks into your existing tooling.

For each major risk, decide:

• What signal indicates it’s happening?

  • Errors? Timeouts? Log patterns? Spikes in support tickets?

• Where will we measure that signal?

  • Metrics dashboards (e.g., Prometheus, Datadog, CloudWatch)
  • Logs (e.g., ELK, Splunk)
  • Traces (e.g., OpenTelemetry, Honeycomb)
  • Session or event analytics (e.g., Amplitude, Mixpanel)

• What alert threshold triggers action?

  • ">2% double-charge errors in 5 minutes" → page on-call
  • "Checkout latency over 2s for EU users for 10 minutes" → auto-roll back canary

On the threat map, note for each risk:

• Signal: what we watch (metric, log pattern, trace span, session event)
• Alert: threshold and channel (Slack, pager, email)
• Response: first step (rollback, disable flag, increase rate limit)

Now the map is not just a pre-launch exercise; it’s a guide for on-call response if things go sideways.

Keep It a Living Artifact

The worst thing you can do is treat the threat map as a one-time checklist.

Instead, bake it into two recurring rituals:

1. Release planning

Before each phase of rollout (beta → 10% → 100%), quickly revisit the map:

• Have any risks changed due to new code or architecture?
• Can we lower our concern for some risks based on real data?
• Do we need new mitigations or tighter alerts for full rollout?

Update the map, even if it’s just a few annotations. Store it alongside your release notes or in the same doc as your runbook.

2. Post-incident reviews

When something does go wrong:

• Pull up the original threat map.
• Ask: Was this risk on the radar? If not, why not?
• If it was, were mitigations sufficient and actually in place?
• How should we update the dimensions, mitigations, and signals based on what we learned?

Then revise the map and, if applicable, your template so future teams benefit. Over time, this builds a library of patterns: you’ll start seeing the same kinds of risks and mitigations repeat, which speeds up future mapping.

Conclusion

You don’t need a heavyweight process to catch most of the scary issues lurking in major releases. You need a shared picture of where your risks live and how you plan to handle them.

The Analog Incident Radar gives you:

• A one-page, visual threat map for each risky feature
• A common language for product, engineering, and security to talk about risk
• A direct link between risks, mitigations, and observability signals
• A living artifact that evolves with your releases and incidents

The next time you’re about to ship something that makes you slightly nervous, pause for an hour. Grab a whiteboard or a simple drawing tool. Sketch your threat map. Argue about it. Attach concrete mitigations and alerts.

That single page might be the difference between a smooth launch and your next major incident review.