Blog

What to put on a customer status page during a vendor incident

2026-08-22

When a dependency is degraded and your product feels it, customers need measurement language, not a calm green badge. A practical template from the August 2026 GitHub outage.

Your product depends on someone else's API, auth plane, or CI. That dependency has a bad day. Support starts filling up. Marketing wants a green badge. The question is not whether to update your customer status page. It is what honest words go on it when the failure is partly theirs.

A recent case: GitHub, 17 August 2026

On 17 August 2026, GitHub reported a multi-hour incident that disrupted github.com, authentication, Actions, APIs, pull requests, issues, and Copilot. GitHub's own follow-up put the duration at 7 hours and 47 minutes. Public coverage from The Register and TechSpot matched the status-page framing: roughly 20% error rates on web and API traffic, about 50% on archive and raw repository downloads, while some surfaces such as Git operations stayed up for many users. GitHub later published its own account of capacity pressure in a Central US data center and a retry storm that slowed recovery.

That is the shape of a vendor incident most teams actually face: broad enough that your product path breaks, narrow enough that a single "GitHub is down" slogan is wrong, and long enough that customers will check your status page before they finish reading the vendor's.

We do not invent StackWitness probe outcomes for that past window here. For a live outside view of host reachability next to GitHub's self-report, see /status/github. Reachable still means the host answered a probe. It is not a certificate that every GitHub feature worked for every customer.

What customers need from you

They need three facts, in plain language:

• What is broken for them - the product surface they use (login, checkout, deploys, webhooks), not your internal service name.
• What you believe the cause is - your stack, a named dependency, or still unknown. Name the vendor and the component when you have that signal.
• What you are still measuring - if signals disagree, say they disagree. "We are still measuring" beats a false-calm green.

They do not need a compliance-sounding verdict, an SLA lecture, or a marketing softener that implies nothing important failed.

Copy you can paste (and adapt)

When the vendor has opened an incident and your errors line up:

We are seeing elevated errors on [your surface]. [Vendor] reports degraded [component] as of [time UTC]. Our own systems outside that dependency look healthy. We will update this page when their status changes or when our measurements move.

When you feel pain but the vendor badge is still green:

Customers in [region / path] are seeing [symptom] on [your surface]. We have not yet seen a matching public incident on [vendor]'s status page. We are checking an outside reachability view of their host and our own error rates by region. We will not mark this operational until those signals agree.

When only part of the dependency is red:

[Vendor] marks [component] degraded; [other component] remains available per their status. Impact for us is limited to [your surface]. Other product areas that do not call that component are not covered by this incident update.

What not to publish

• Do not flip the whole product to green because the marketing site still loads.
• Do not blame "intermittent network issues" when you already have a named vendor incident with timestamps.
• Do not claim you "verified full restoration" from a single successful page load or a single region.
• Do not invent probe results you did not collect. Attribute vendor status, your APM, and any independent reachability view separately.

Keep a timestamp trail on the page

Every update should carry a UTC time. Note when customer symptoms started, when the vendor status moved, and when your outside checks changed. That trail is what you will need for a postmortem and for customers who only open the page hours later. A status page without times is a rumor board.

Operator checklist

1. Name your broken customer surface first.
2. Name the dependency component second (API, auth, Actions, webhooks), with a link to the vendor incident if public.
3. Separate host reachability from product health. A reachable host can still fail the feature you call.
4. Say what is not in scope so you do not over-claim outage or under-claim impact.
5. Update on a clock, even if the text is "no change; still measuring."

StackWitness measures reachability and reads vendor self-reports so teams can attribute faster. We do not certify that a vendor met an SLA, and we do not issue a compliance verdict. During a vendor incident, your customer status page is where honesty either compounds trust or spends it. Prefer measurement language over calm green.