Trust your own measurements and gather evidence. A status page reports what the vendor has detected, and partial failures can affect some customers, regions or request types while their checks stay green. Confirm your impact, narrow it down, and send the vendor a short report with timestamps and request identifiers.
Why the gap exists
The AWS Builders Library article on health checks describes why detection is hard. A server may fail in ways that look like the client's fault, such as returning a 400 instead of a 500. Servers may slow down instead of failing, or respond faster than their peers, which can be a sign they are returning false responses. Anomaly detection, comparing each server against the rest of the fleet, is described there as a way to catch divergence a server cannot detect about itself, including clock skew and outdated code.
The same difficulty applies to a vendor's public status. Overall indicators can look healthy while a slice of traffic is failing. This post makes no claim about any particular provider. It is a way to behave when you see a mismatch.
Step one: confirm it is you or them
| Check | What it tells you |
|---|---|
| Try from another network or location | Rules out your local path |
| Try another account, region or endpoint | Shows whether the issue is scoped |
| Compare with a known good request | Separates broken requests from a broken service |
| Look at your own error rate over time | Gives a start time and shape |
| Check your own recent changes | Many "vendor problems" follow a local change |
Do not skip the last row. Check deploys, configuration changes, certificate renewals and credential rotations around the time the errors began.
Step two: collect evidence
- Record the first and last error times in UTC.
- Save a few failing request identifiers or traces, with sensitive data removed.
- Note which endpoints, regions and customer segments are affected and which are fine.
- Capture the exact error codes and messages.
- Write what you changed on your side, even if you think it is unrelated.
Step three: report it usefully
A good report is short and specific: what you expected, what happened, when it started, how many requests, a sample identifier, and what you have ruled out. Use the vendor's support channel and reference an incident number. Avoid speculation about the cause.
Step four: protect your users meanwhile
- Check whether you can use a fallback or degrade gracefully, as in our post on designing a degraded mode.
- Update your own status page with what you see, in neutral words. Our post on outage or incident wording can help.
- Avoid retry storms. If your clients retry aggressively against a struggling service, you add load. See retry storms.
Build your own signal
If you depend on a vendor for something important, measure it yourself with a simple synthetic check that runs from outside your network, so you do not rely on their page alone. Keep the history. It helps in a later conversation about service credits or reliability, and in your own continuity planning.
A worked example: errors that some users see
This example is hypothetical. A team gets reports that image uploads fail for some customers. The vendor's status page shows all systems normal. The team investigates in order.
| Check | Result | What it suggests |
|---|---|---|
| Reproduce from the office network | Fails about one in three attempts | Not a total outage |
| Reproduce from a mobile network | Same pattern | Not our local network |
| Try a different region endpoint | Works every time | Problem seems scoped to one region |
| Try with a tiny file | Works | Size related |
| Review recent changes on our side | A client library update shipped yesterday | A possible local cause too |
| Roll back the library in staging | Still fails | Local cause is less likely |
The pattern suggests a scoped problem on the vendor side: one region, larger payloads, intermittent. The team writes a report with timestamps, request identifiers, the region comparison and the file size observation. It also switches uploads to the other region as a stopgap if its architecture allows.
Step by step: an escalation template
- Title: one line stating the symptom and scope.
- Start time and, if known, the last good time in UTC.
- What you expected and what you observed, with the exact error text.
- Scope: regions, endpoints, accounts or request sizes that fail and those that do not.
- Evidence: a few request identifiers or trace links with sensitive content removed.
- What you ruled out, including your own recent changes.
- Impact on your customers and any deadline.
- Contact details and a good time to reach you.
Keep it under one screen. A short, concrete report is more likely to reach the right engineer than a long narrative.
Meanwhile, protect your users
Choose a workaround that you can undo. Switching a region, queueing uploads for later or showing a clear message are all reasonable. Tell customers in plain language what you see and what you are doing, without blaming anyone. Avoid retry loops that multiply load on a struggling service. Our post on customer updates during an outage helps with wording.
Measure it yourself
If a vendor matters, set up a synthetic check that performs a real operation, such as uploading a small file, every few minutes from at least two locations outside your network. Store the results. When something happens you will have your own timeline. When it does not, you will have a baseline. That history is also useful in contract reviews and in your continuity plan.
Learn from it afterward
After the event, hold a short review. How long did it take to decide it was the vendor? Did the status page eventually reflect the problem, and how long after? What did you learn about your dependency on that region or feature? Add a line to your dependency list, as in our post on which vendors you cannot run without.
Try it yourself
Open the continuous monitoring demo and look at how repeated checks produce a record over time. A synthetic check of a vendor does the same job: it gives you your own evidence.
Click through it at your own pace, or open it full screen.
Quick check
Is the status page wrong?
Not necessarily. It may lag, or it may measure something different from what you use. Treat it as one input, not the final word.
Who should I tell first?
Your own on call and incident lead, so the response is coordinated. Then send the vendor a concise report with evidence.
Should I wait for the vendor to acknowledge the problem?
No. Begin your own mitigation and communication based on what you observe, and update when the vendor confirms or clears it.
Sources
Last reviewed: 19 October 2026.
