Your competitor is down. Now what?

You will want to tweet about it. Don't.

A competitor's major outage is the rare competitive event that arrives with a countdown. Their status page turns red, their customers get loud on social media, and somebody in your sales channel posts a screenshot with a popcorn emoji. For a few hours it feels like the market is handing you a gift.

It is a gift, but a different one than it looks like. The outage itself wins you almost nothing. Customers don't switch vendors during an incident; they wait it out and remember how it was handled. What the outage gives you is information that is public for a short window and then gets edited, summarized, or quietly removed. The first 24 hours are about collecting that information and making three decisions calmly.

Here is the sequence.

Step 1: Capture the record while it is still raw (hour 0–2)

Incident pages get rewritten. The first update says "investigating elevated error rates in our EU region". The final version says "a subset of customers experienced degraded performance". The first one is the useful one.

• Save the status page now, and again every time it updates. Timestamps matter. You want the sequence, not the summary.
• Note which components are marked as affected. The component list is an architecture diagram in disguise, as covered in what a status page reveals about reliability.
• Record the time of the first acknowledgement. The gap between customers complaining publicly and the vendor admitting it tells you how their on-call works.
• Screenshot customer reports that name a specific impact. "Our checkout was down for 40 minutes" is evidence. "lol they're down again" is not.

This is the one step where automation plainly beats a person. Nobody is refreshing a rival's status page at 3 a.m. Seeto monitors public surfaces like status and trust pages continuously and records each edit as a discrete change event, so the original wording survives after the page is tidied up. It will not judge how severe the incident was or what caused it. It keeps the record so that you can.

Step 2: Send one internal brief, and make it boring (hour 2–4)

Your team already knows. What they lack is a shared, accurate version. Without one, every rep improvises.

• State facts only: what is down, since when, which regions or products, and a link to the source for each claim. The rule from every competitor claim needs a source link applies twice as hard today.
• Say what is unknown. Cause, data loss, and duration are usually unknown on day one. Write "unknown", not a guess.
• Give one instruction to sales and support: do not raise the outage with prospects or customers. If they raise it, answer with facts and move on.
• Name one person who owns updates. One thread, one owner, until the incident closes.

A boring brief prevents the exciting mistake. The exciting mistake is a rep emailing forty prospects with "saw the news about your vendor".

Step 3: Decide what you will not do (hour 4–8)

Most of the damage a team does during a rival's outage is self-inflicted. Make these decisions explicitly, in writing, before someone makes them by accident.

• No public commentary. No jokes, no "we're up!" posts, no founder quote-tweets. Your own outage is coming eventually, and the internet keeps receipts.
• No outage-themed ads or landing pages. They read as opportunism to the exact buyers you want: the careful ones.
• No reliability claims you cannot back. If you have not published your own uptime history, today is a bad day to start boasting about it.
• No roadmap changes. One incident is not a trend. The same logic as reacting first is overrated holds here.

There is one thing you should do in this window. Check your own exposure. If the outage came from a shared cloud region or a shared vendor, you may be next, and your status page should say something before your customers ask.

Step 4: Open the door quietly (hour 8–24)

Some of their customers will start looking. They will not announce it. They will search, read your docs, and check whether leaving is even possible.

• Make sure your migration and import docs are current. A stale import guide loses the buyer who arrives today.
• Check that your own status page and uptime history are easy to find. Evaluators will look for them first.
• Prepare sales for inbound, not outbound. Give reps a short, factual answer to "how do you handle this kind of failure?" that describes your own architecture and does not mention the competitor.
• Tag inbound leads from the window. You want to know in a quarter whether the outage produced pipeline or only noise.

Quiet availability beats loud opportunism. The buyer who switches after an outage is choosing the vendor that looked calm.

Step 5: Read the post-mortem when it lands (day 3–14)

The real intelligence arrives later, in the incident review. Put a reminder on the calendar, because by then your team will have moved on.

• Compare the review to the raw record from Step 1. What got softened? What disappeared?
• Read the remediation list as a roadmap. "We are migrating to multi-region failover" tells you where their engineering quarters are going.
• Watch for follow-up changes on other surfaces: new SLA wording, a new subprocessor, a reliability hire on the careers page.
• Update the battle card once, with dates and sources. A single line: what happened, how long, what they committed to fix.

Then check back in 90 days to see whether the commitments shipped. A vendor that does what its post-mortem promised is a stronger competitor than before the outage. A vendor that doesn't has given your sales team a fair, documented point.

The outage is not the story. How they handle the next two weeks is, and you can only read that if you kept the first two hours.