Back to blog
2 min read
IncidentsGuide

How to explain downtime to non-technical founders and investors

They do not need Kubernetes. They need impact, duration, cause at the right altitude, and what changes so it is less likely next time.

NK

Nabin Khair

Founder

After a bad outage someone asks for "a quick summary for the board." Paste a Slack thread and you look chaotic. Give a ten-page RCA and you look evasive. Use a short script.

The four beats

  1. What customers felt: could not log in for 42 minutes; checkout failed for EU users; etc.
  2. How long: detect โ†’ mitigate โ†’ full restore.
  3. Why, in one sentence: bad deploy; vendor DNS; certificate; capacity.
  4. What we change: better check; maintenance windows; rollback drill; capacity headroom.

If you do not know (4) yet, say when the postmortem lands, then keep that promise (small-team postmortem).

Words that help

  • "We were down" or "degraded" with the definition you use publicly
  • Minutes and scope, not "briefly"
  • "Our monitoring caught it in X minutes" or "a customer caught it first" (both honesty)

Words that hurt

  • Blame storms about a junior engineer
  • Untranslated acronyms
  • Guaranteed never-again promises
  • Fake precision ("exactly 99.992%") when your monitors cannot support it

Metrics they might ask for

Translate nines into hours. Mention MTTD/MTTR only if you will explain them in a clause each. Point to the public status history if it exists; third-party visible truth beats a slide.

Calm, specific, forward-looking. The product is trust. Downtime is a withdrawal. The explanation is how you deposit again.

Keep reading

More from the Tallwatch blog

More on monitoring, alerting, and status pages.