A clean codebase can still derail a deal if incidents linger in production. A buyer may discover that every Sev-1 outage took an average of 6 hours to resolve, even though the team promises a sub-hour Mean Time to Recover (MTTR). No one wants to pay a full multiple for a platform that lost half a business day each time it hiccupped. Speed matters, accuracy matters even more. Some of these metrics I already mentioned in Edition 3, but now I'm writing with lens of Operational Excellence and Incident Response practices.

Why incident response sits on the due diligence critical path

Investors track uptime, but they worry even more about how quickly you bounce back when things break. A short MTTR limits SLA credits, protects NPS, and keeps churn down. Fast containment (MTTC) also signals mature on-call practices, clear ownership, and a culture that learns rather than blames. If recovery is delayed or post-mortems gather dust, buyers assume hidden debt in monitoring, run-books, and team structure. They will discount accordingly.

The metrics that tell the real story

Important operational metrics teach us about detecting downtime and incidents, acknowledging and containing them, recovering and learning from them.

  • Mean Time to Detect (MTTD) shows how long it takes the monitors (not the customers) to realize something is wrong. Sub-5-minute MTTD conveys that observability is wired into every layer while double-digit minutes hint at blind spots.
  • Mean Time to Acknowledge (MTTA) is about hand-off from machine to human. A healthy on-call rota keeps MTTA in the low single digits, but anything beyond 10 minutes shouts "pager fatigue" or thin coverage.
  • Mean Time to Contain (MTTC) measures how fast damage is halted even if the full fix takes longer. A strong containment metric shows good alerting, well-defined playbooks, and confidence in rollback tools.
  • Mean Time to Recover (MTTR) is the headline: the clock starts when a customer feels pain and stops when normal service resumes. For growth-stage SaaS, anything under an hour for Sev-1 incidents calms investors. A drift toward 2-3 hours raises eyebrows.
  • Change Failure Rate (CFR) pairs with MTTR. If fewer than 15% of deployments trigger incidents, automated testing and progressive delivery are doing their job.
  • Investors also understand incident post-mortem velocity: not just whether a document exists, but how quickly it is written, shared, and closed out with follow-up tasks. A 5-day turnaround on write-ups and a short window to burn down action items indicate a learning organization.

How stage and stake sharpen the lens

Seed or early Series A backers tolerate informal on-call rotations and Google Doc post-mortems, provided the team can point to improving MTTR trends. By Series B, buyers expect real on-call schedules, PagerDuty data, and monthly incident reviews. In control buy-outs the bar rises again: investors want hour-level graphs, compliance-grade run-books, and tracking of follow-up work to completion. The larger the cheque and the more control it buys the deeper investors drill.

Red flags that lengthen negotiations

If incident dashboards show spikes that aren't explained, if major outages lack post-mortems, or if the same root cause appears 3 quarters in a row, diligence slows. Investors must model churn risk and SLA credits, so they build extra buffer into the price.

Habits worth adopting before the next term sheet

The goal is to show a reliability culture that's measurable, repeatable, and not personality-driven.

  • Measure everything you can, but at least MTTR and CFR. That's the bare minimum.
  • Run a periodical incident-review. Invite engineering, support, customer success and product and review MTTR, MTTC, and CFR trends. Keep the agenda tight: what happened, why it mattered, what has already been fixed, and which follow-ups remain.
  • Publish a public-facing uptime page fed directly from your monitor. Nothing builds trust faster during due diligence than a third-party chart showing 99.96% over the past twelve months.
  • Automate "first-5-minutes" actions. Pre-built scripts that flip feature flags, roll back canary pods, or increase replica counts cut containment time in half and impress investors who understand operational excellence.
  • Close the loop on post-mortems. Assign an owner, set a due date, and track action items in the same backlog as features. Burned-down debt is visible proof of learning.
  • Rotate on-call with follow-up rest. A humane schedule keeps engineers sharp and retention high so MTTR stays low without burning out talent. This is typically well regulated in the law (e.g. in Germany).
  • Schedule an annual third-party "chaos" or controlled-incident exercise. When outside facilitators inject surprise failures: DNS black-holes, database corruption, credential leaks, your engineers rehearse under pressure while observers time the metrics and note playbook gaps. The report becomes instant diligence evidence that you test resilience, not just talk about it.
  • Formalize a 1-2-3 support ladder. Level-1 responders (support or SRE) triage and apply run-book fixes; level-2 engineers dig into code; level-3 (staff or architects) own systemic remediation. Documenting the structure, with escalation timers and after-hours rotations, tells investors incident response won't bottleneck around a single heroic CTO.

Common traps

Slashing cloud-monitoring budgets right before diligence leaves gaps in incident logs, buyers wonder what else is missing. Counting only "declared" incidents hides near-misses that matter just as much to future reliability. Pushing every post-mortem into a shared folder but never checking whether fixes shipped convinces no one.

Mini-Glossary

  • MTTR (Mean Time to Recover): average time from user impact to full restoration.
  • MTTC (Mean Time to Contain): time from alert to halting customer pain.
  • CFR (Change Failure Rate): percentage of deployments that trigger incidents or rollbacks.
  • Post-mortem velocity: elapsed time from incident close to documented, accepted retro with actions underway.

Your turn

What's the toughest incident you've had to explain during diligence? A silent data-loss bug, a runaway queue, or a 3-hour DNS outage? How did you prove it wouldn't happen again? Share your scar stories below.

Founders: Need a second set of eyes on your incident metrics or post-mortem workflow? Let's talk.

Investors: Need more clarity on the operational excellence and the internal culture of your target company? Let's talk.

Next in the Playbook

Edition 7 tackles build-versus-buy decisions and how investors weigh home-grown innovation against third-party lock-in. Subscribe and it will land in your inbox.

Originally published on the Tech Due Diligence Playbook newsletter on LinkedIn.