What should a startup tell prospects about an outage mid-deal?

Tell them first, before they hear it from someone else. Send every open prospect a short, plain note: what broke, how long it lasted, whether their trial or data was touched, what you changed so it won't repeat, and where to check status. A prospect who hears about your outage from you watches how you handle a bad day. A prospect who finds it on social media starts wondering what else you're not saying.

Why does an outage hit deals so hard?

Because the buyer is still deciding whether to trust you.

A customer who has used you for a year has context. A prospect in a trial has a week of impressions, and one of them is now your product being down. Startups already carry extra doubt. Buyers ask what happens if your startup goes under. An outage hands that doubt a fresh example.

It's also the one moment a buyer gets to see how you act when something breaks. That's a big part of what they're buying.

Who should I tell?

Every open deal that could have noticed, plus every one where the outage was public.

• Active trials and pilots. First, with specifics about their account.
• Late-stage deals. Tell the champion directly, so they aren't surprised in an internal meeting.
• Early-stage deals. A short note if the outage was public or long. Skip it for a five-minute blip nobody could have seen.

Your champion has to defend you internally. Give them the words before someone asks.

What should the note say?

Five facts, no spin.

1. What happened, in one sentence a non-engineer understands.
2. When, and for how long, with time zones.
3. What it touched for them: their trial, data, integrations. Say "your data wasn't affected" only after you've checked.
4. What you changed so this specific failure won't repeat.
5. Where to look: your status page and, if you publish one, the incident write-up.

Here's an example:

Hi Dana, heads up before you hear it elsewhere. The app was down from 9:10 to 10:25am CT today after a configuration change failed during a deploy. Your trial data wasn't affected. I checked your workspace myself. I've added a check that blocks that kind of change before it ships. The full write-up is here, and live status is always here. Happy to walk your IT lead through it.

It comes from a person, says what happened, and offers a next step.

What does a good incident write-up look like?

Cloudflare is the public example worth studying.

On November 18, 2025, Cloudflare's network began failing to deliver core traffic. The same day, CEO Matthew Prince published a detailed postmortem on the company blog. It had a timeline, the root cause (a database permissions change that doubled the size of a file Cloudflare's Bot Management system depends on), and what the team got wrong at first: they initially suspected a hyper-scale DDoS attack. The post said plainly, "We know we let you down today," and apologized for the impact on customers and the Internet.

You don't need Cloudflare's scale. You need its habits: a timeline, the real cause, the wrong turn you took while diagnosing it, and the fix. A startup can ship that faster than any big vendor.

Should I offer a credit or discount?

Not to prospects. Offer proof.

Discounting a deal because of an outage tells the buyer it was worse than you said, and it teaches them your price moves. Here's how to handle discount requests if they ask anyway. Offer what answers the real worry instead: your status history, the uptime commitment in your contract, a call with the engineer who fixed it, and your incident process in writing. For paying customers, follow your SLA.

How do I keep it from stalling the deal?

Put it in the plan and keep moving.

Add a line to the mutual action plan: "Incident review with IT, 30 minutes, owner: me." That turns a vague worry into a scheduled step with an owner. Add the write-up to your trust page next to your security documents. Buyers, and increasingly buyer agents, look there.

Then go back to the next step you'd already planned. If you're in a pilot, keep the pilot's success criteria where they were. Don't let one bad hour become a two-week pause.

What mistakes turn an outage into a lost deal?

• Saying nothing and hoping they didn't notice.
• Blaming a vendor without saying what you'll change.
• "Your data is safe" before anyone checked.
• A wall of engineering jargon the champion can't forward.
• Discounting to make it go away.

What should I do this week?

1. Set up a public status page if you don't have one.
2. Write an outage note template with the five facts.
3. Decide who sends it to prospects: the founder or the deal owner, never a no-reply address.
4. Add an incident write-up section to your trust page.
5. Next time something breaks, send the note within a few hours.

Every vendor has outages. Prospects remember the ones they heard about from someone else.

Start Signals, Convert, Grow

FAQ

Should I tell prospects about a small outage?

If it touched their account or was visible in public, yes. A short note costs you a few minutes. Finding out on their own costs you trust. Skip only blips nobody could have noticed.

Who should send the outage note?

A person the prospect already knows: the founder or the deal owner. A no-reply announcement reads like damage control. A note from a person reads like accountability.

How soon after an outage should I contact prospects?

The same day, ideally within a few hours of recovery. Send a short note first and the full write-up when it's ready.

Should a startup publish public postmortems?

For anything customers noticed, yes. A clear write-up with a timeline, cause, and fix is proof you can show every future buyer who asks how you handle incidents.