You're working on something else when a Slack message comes in: "Did you see this?" It's a screenshot of a social media post, fifteen minutes old, with thirty replies. Someone is loudly complaining that your product is down. Other people are confirming. Your status page, when you check it, says everything is operational.

Welcome to one of the more uncomfortable scenarios in modern incident response: customers caught your outage before you did.

This happens to every team eventually. Detection is hard. Customer reports propagate fast. Third-party tools that aggregate complaints in real time can flag an outage before your monitoring does. Sometimes a service has degraded for an entire region you don't probe from. Sometimes your monitoring is right and the outage is small enough that one customer with a popular account can produce more visible noise than the actual incident warrants.

Whatever the cause, you're behind. Here's how to catch up without making it worse.

The first move: don't pretend

The instinct is to scramble. Get the status page up first, then respond on social media as if you'd been on it the whole time. Don't.

Customers can see the timestamps. The status page entry that goes up at 14:30 saying "investigating since 14:25" looks dishonest to anyone who saw the social media report at 14:10. The pretense lasts about as long as it takes someone to compare timestamps and post the comparison.

A more honest opening, as a quick acknowledgment on the social media thread:

"We saw the reports — confirming now. Status page being updated."

That's the entire first response. Brief. Not defensive. Acknowledges the social signal without trying to explain why your detection lagged. Buys you the next few minutes to actually investigate and post.

The catch-up: status page first, then reply

After the brief acknowledgment, get the status page entry up. Don't reply to every social media post yet — that's a black hole of attention you don't have during an active incident.

The status page entry at this stage is the same as any other initial entry: what's broken (in customer language), who's affected, what's next, time of next update. The fact that you're behind doesn't change the format.

Then, with the status page live, you can reply to the original social post with something like:

"Update posted on our status page: [link]. We're seeing what you're seeing — investigating now. Updates will go through the status page."

That redirects the conversation from social media (where it's noisy and unstructured) to the status page (where you control the narrative). It also prevents you from having to repeat the same update in twelve different reply threads.

When the social post is wrong

Sometimes the post got the wrong end of the story. A customer says your API is down; investigation shows their API key was revoked yesterday. A customer says checkout is broken; investigation shows it's a regional CDN issue affecting only one country and only some customers there.

When the social post is partially or entirely wrong, you still acknowledge — but you correct the narrative gently:

"Looking into this — we're not seeing a broad outage on our end yet, but we're checking specifically for the issue you described. Will update."

Then a follow-up once you know:

"Confirmed: this looks like a localized issue. Customers in [region] may experience [specific symptom]. We're working on it. Status page is updated: [link]."

Specifically don't:

Argue with the original poster publicly. Even if they're wrong, the optics of a vendor account arguing with a frustrated customer are bad.
Ignore them and post your own update without acknowledging theirs. That reads as defensive.
Correct them in a way that sounds like you're blaming them ("You may have a stale API key from last quarter"). That might be true but not the right thing to say in public. Reach out privately if it's a customer-specific issue.

The principle is: the social post raised a signal. You're responding to the signal honestly. If the signal was incomplete, your response can clarify without making the original poster look foolish.

The harder version: when there's no real incident

Sometimes a social post claims an outage that you genuinely cannot reproduce. Monitoring is green. Customer reports are zero. The original poster is the only signal.

Treat this as a one-customer report (see What to Do When You're Not Sure If Something's Broken). Investigate. Reach out to the original poster directly if you can:

"Saw your post — we're not seeing this in monitoring or other reports. Would you mind sharing the specific URL or action you were taking? Want to make sure we're not missing something."

That serves two purposes. First, you might be missing something — see When Monitoring Says Green but Customers Say Broken. Second, the original poster sees you taking the report seriously, which often de-escalates the public side of the conversation.

Don't post on the status page yet — there isn't a confirmed incident. Don't reply publicly disputing the post — that goes badly. The DM-and-investigate path is almost always better than the public-back-and-forth path.

After the dust settles: don't be defensive about the lag

Once the incident is resolved, customers who saw the social post and the lag will remember. The temptation is to glide past it in your resolution update. Don't.

The resolution update for an incident where you were caught late should briefly acknowledge it:

"Resolved at 15:18. Login was unavailable for 36 minutes. Our automated monitoring didn't catch this as quickly as it should have — we've added a check for the specific failure mode so similar issues are caught faster in the future. A full write-up will be published within 48 hours."

That last sentence about the new check is what turns "caught late" from a black mark into a credible story. The team noticed the gap, identified the fix, and acted on it. That's a much better narrative than silently hoping nobody remembers.

Closing the detection gap

The longer-term fix for "customers caught us first" is closing the specific gap that caused it. Some patterns:

Add monitoring for the path customers reported. Each "customers caught us first" incident produces a specific lesson — a check that should have existed.
Subscribe to your own status page from a non-work email. If you'd have seen the customer report on your own status page subscriber list, that's a feedback loop to your team.
Set up social listening for your product name. Free tools (search alerts, social media saved searches) can flag mentions of your product name in real time. The cost is occasional false positives; the benefit is catching the real ones earlier.
Add a customer report intake on the status page itself. A "report a problem" button that creates a support ticket and pings the on-call engineer. Some teams resist this because they assume customers will misuse it; in practice, the noise is manageable and the signal is excellent.

You don't need all of these. Pick the one that matches the gap that just bit you, ship it, move on.

The cultural piece

The teams that handle this scenario well share a posture: they're not embarrassed by being caught late. They acknowledge it, they explain what they're doing about it, they move on. The teams that handle it poorly try to pretend it didn't happen, or get defensive about the lag, or argue with the original poster.

The status page doesn't need to be first. It needs to be authoritative. Even when customers post about your outage before you do, your status page is the place customers will go to find out what's actually true. Your job is to make sure it has that information, in customer language, with honest timestamps — and that the path from "customer report on social media" to "authoritative update on your status page" is short enough that customers learn to wait for the status page rather than treating social media as the source of truth.

You won't always be first to detect. You can always be the place that has the most accurate, most useful, most current information about what's actually happening. That's the prize.

PageCalm helps small teams run status pages with AI-powered incident updates that sound human and ship fast. Try it free — no credit card required.

What to Do When Customers Post Your Outage Before You Do