Blog

Partial outages: why one green average lies

2026-08-10

When one product is red and the rest look fine, a single operational badge hides the real story. How to read component status, region disagreement, and host reachability without inventing calm green.

Most vendor outages are not total blackouts. They are partial: one product surface fails while the marketing site loads, one region times out while another answers, or CI is stuck while git clone still works. A single green "operational" badge averages those truths into a lie that costs you hours in the wrong place.

A recent example: Actions and Pages, not "all of GitHub"

On 6 August 2026, GitHub's own status page opened a critical incident for Actions. Workflow runs failed to start or failed mid-run, and the Actions REST API returned errors. Pages was pulled into the same incident with degraded availability. Public coverage from The Register and GitHub's status history match that framing: component-level pain, not a claim that every GitHub surface was offline for every user.

That pattern is the lesson. Your deploy pipeline can be dead while github.com still answers an outside probe. Your static site publish can lag while Issues still load. If your only signal is a top-level green light, you will debug yourself for an hour when the honest update was "Actions is degraded per vendor status; host reachability is a separate question."

Three signals, not one badge

When something feels wrong, separate the columns:

• Vendor component status - what did their page say about the specific product you depend on (API, auth, webhooks, Actions, billing)? A global operational summary can stay green while one component is red.
• Independent host reachability - did the public service host answer probes from outside your network? Reachable means the host answered. It is not proof that every feature works.
• Your path and your region - errors only in one region, one account tier, or one API route are still an outage for you. Averaging them into "mostly fine" is how customer updates go false-calm.

StackWitness puts independently measured reachability next to vendor self-report on free public truth pages (for example /status/github). We do not invent probe outcomes for a past incident we did not pin here, and we never turn a handshake into a product-health certificate.

Region disagreement is partial outage with a map

Partial outages also show up as geography. Two edge regions reach the host; one does not. Or vendor status is quiet while your EU customers see timeouts and US customers do not. That is not "flaky monitoring." That is the outage shape. Collapsing regions into one green average is how teams reopen closed tickets with "works for me."

When you write the customer update, name the split: which region failed, which product component the vendor marked degraded, and what you still do not know. "We are still measuring" is honest. "All systems operational" when checkout is failing is not.

What not to do at 3am

• Do not rewrite history with a deploy "fix" until you know whether the failure is inside your network.
• Do not treat "homepage loads" as proof that the API, webhooks, or CI plane is healthy.
• Do not invent a calm green status page update to quiet support while independent signals still disagree.
• Do not wait only on the vendor's global badge. Read the component timeline and keep a timestamp trail for later.

Operator checklist

1. Name the dependency and the product surface you actually call (not the brand).
2. Check the vendor status page for that component, with timestamps.
3. Check an outside reachability view of the service host, by region if you have it.
4. Compare to your own error rates by region and path.
5. Write the customer update from those facts. If signals conflict, say they conflict.

We measure reachability and read vendor self-reports. We do not certify that a vendor met an SLA, and we do not issue a compliance verdict. Partial outages are where honesty matters most: one green average is often the most expensive lie in the stack.