How a Transparent Outage Report Won Us a Contract

The Incident That Became a Sales Tool

Last year we had an outage. Not a blip. Not a "degraded performance" footnote buried in a status page. A real outage—one that affected paying customers during business hours for longer than anyone on the team was comfortable with.

What happened next didn't follow the standard playbook.

What Went Wrong

The details matter less than what we chose to do with them, but here's the short version: a configuration change that had been tested in staging behaved differently in production under real load. Monitoring caught the symptoms, but the on-call engineer misread the initial signal and spent twenty minutes investigating the wrong subsystem. By the time the actual cause was identified and rolled back, customers had experienced nearly fifty minutes of errors.

Fifty minutes. For a company that promises reliability, that number stings.

The Instinct to Minimize

After the dust settled, we had a draft incident report within hours. The first version was accurate but careful. It described the technical chain of events in passive voice. "A configuration change was deployed." "The issue was detected." Nobody's name appeared. No mention of the twenty minutes spent chasing the wrong lead.

Reading it back, it sounded like something a legal team had scrubbed. Technically true, emotionally dishonest.

We rewrote it.

What We Actually Published

The second version named what really happened—not just the technical failure, but the human one. The on-call engineer misread the alert. Our runbook for that failure mode was out of date. The escalation to a second engineer happened ten minutes late because severity was initially classified too low. We explained what we were changing: updated runbooks, a revised severity classification process, and a new rule that ambiguous alerts get escalated immediately rather than investigated solo.

We published that version to every affected customer. Not behind a login wall. Not in a PDF attached to an email. On our public status page, with a direct link shared in our community channels.

Some people on the team were nervous. Understandably so.

The Call We Didn't Expect

About three weeks later, we were in a final evaluation with a prospect—a mid-market company with a serious procurement process. They'd been running a parallel evaluation with a competitor for months. Their head of engineering joined the closing call, which usually means hard technical questions are coming.

Instead, she opened with this: "We read your incident report from last month. That's why we're here."

She explained that the competitor had also experienced downtime during the evaluation period. Their response was a short email: "We experienced a brief service disruption. The issue has been resolved." No root cause. No timeline. No mention of what would change.

The contrast was striking, she said. Not because we had the outage—she expected outages from any vendor. But because our report made it obvious we understood what broke and had a concrete plan to prevent recurrence. The competitor's response left her wondering whether they even knew what had gone wrong.

They signed the following week.

Why Transparency Beats Perfection

Every founder has sat through a demo where the product works flawlessly. Demos always work. Staging environments are calm, predictable places. Nobody evaluates a vendor based on how their product behaves when everything is fine.

The real question prospects are trying to answer—even if they never say it out loud—is: what happens when something goes wrong?

A polished demo answers the easy question. An honest incident report answers the hard one.

The Trade-Off Is Real

Publishing a detailed incident report has costs. Competitors can point to it. Early-pipeline prospects might see it before they understand the context. A customer who wasn't affected by the outage now knows it happened.

We accept those costs because the alternative is worse. A vague incident response doesn't make the outage disappear—it makes your customers wonder what you're hiding. In B2B, uncertainty is more damaging than a known problem with a known fix.

What a Good Incident Report Contains

We don't have a rigid template, but our reports always cover the same ground:

• What happened, in plain language, with a timeline
• Who was affected and how
• What the human failures were, not just the technical ones
• What we're changing to reduce the chance of recurrence
• What we're not changing and why, if applicable

That last point matters. Sometimes the honest answer is "we accept this residual risk because the mitigation would introduce worse trade-offs." Saying that out loud earns more trust than pretending every risk can be eliminated.

The Lesson

Founders spend enormous energy building trust before the sale. Case studies, testimonials, SOC reports, uptime numbers. All of that matters. But nothing builds trust faster than showing how you behave when things go wrong.

Perfection is not a credible promise. Response is.

The next time something breaks—and it will—resist the instinct to minimize. Write the report you'd want to read if you were the customer. Publish it where people can find it.

Your future customers are watching how you fail. Make it worth watching.