Your push fails, the assistant stops responding, or a deployment sits in a queue. You open the provider's status page. Everything is operational. That does not make your error imaginary, and it does not automatically mean the status page is lying.
Start with an official source, such as GitHub Status, and read the affected components and incident notes. The headline is a summary. It cannot tell you whether your particular request, account or network path worked. This guide explains the gap and how to investigate it without spending the afternoon changing settings at random.
A service contains several services
The name on the browser tab hides separate systems. Source control can work while hosted build jobs cannot start. An AI website can accept a login while one model fails to answer. Messages can arrive while search is unavailable.
Find the component closest to your failed action. If a Git push succeeded but the pull request page looks stale, do not assume your commit disappeared. Those observations concern different operations. Record what succeeded as well as what failed; that boundary is useful evidence.
Status platforms also combine component conditions into a headline. Atlassian explains how Statuspage calculates overall status and incident impact. Those rules belong to that platform, not every status site. Read the provider's own labels instead of assuming that green, yellow and red mean exactly the same thing everywhere.
Your region can fail while another works
A request travels through your network, a resolver, routing infrastructure and the provider's systems. Two colleagues can reach the same hostname through different paths. A successful test elsewhere narrows the problem; it does not disprove a regional incident.
Compare the same operation from another permitted network, or ask a teammate in a different location to try it. Keep the account, project and request as similar as practical. Changing all of them together makes the result harder to interpret.
Look for location names in incident details. A regional issue may affect a small share of users overall while blocking every request your team makes. “Partial” describes the reach of the failure, not how inconvenient it is for you.
The problem may belong to a client or account
An expired session, revoked credential, organization policy, exhausted allowance or browser extension can interrupt a workflow while the service remains healthy. A company proxy can also affect everyone in your office without affecting other customers.
Try one comparison at a time. Does an existing browser session work while the desktop app fails? Does another authorized teammate have the same error in the same project? Does the response mention permissions or a usage limit?
Save unsent work before refreshing or signing out. Avoid clearing every cache, rotating every key and reinstalling the application as your opening move. Those actions erase clues and create new variables. A specific error should guide a specific check.
Reporting takes time
Your failed request and a published incident are different events. A provider may need to detect a pattern, investigate its scope and write a useful update. During that interval, you can have a real service problem with no matching public incident.
Do not invent a fixed delay. Different providers and incidents follow different processes. Note when you observed the failure, keep a request identifier if available, and check for the next official update at a deliberate interval.
You can tell your team that a provider problem is suspected before it is confirmed. Say what you observed and what remains unknown. “Three people cannot start builds; no matching incident has been published” is more useful than either “everything is fine” or “the whole platform is down.”
Cached information can disagree with fresh errors
An old tab, a cached page or a delayed feed can show information from a different moment. Search snippets and screenshots are especially poor substitutes for opening the current incident page. Check the date and timezone on the actual update you are reading.
Refresh the status page once and inspect recent incident notes. If you are comparing a third-party monitor, check whether its record describes the same feature and time period. Do not treat the clock on your computer as the time the provider last reviewed its service.
Caching also works in the other direction: a previously loaded application page can still look healthy while a new operation fails. Test the action that matters, not merely whether the interface appears.
Degraded performance is different from a full outage
Slow responses, intermittent failures and unavailable features can have different labels. An incident marked as monitoring means a mitigation is being observed; it is not a guarantee that your queued work has completed.
Read the description alongside the label. Check the component, affected users, workaround and latest update. Avoid translating every yellow banner into a total outage, or every operational headline into proof that all requests succeed.
Nines uses official outage signals for the components it follows. Yellow or degraded banners alone do not unlock its arcade. That product rule does not decide whether your own workflow is usable.
Use outside reports to find a pattern
Downdetector and social posts can help answer whether other people noticed similar symptoms. They cannot reliably identify the failing component, prove the cause or tell you when recovery will finish. Old posts and broad report categories can confuse the picture.
Compare timestamps and specific symptoms, then return to your own evidence and official updates. For a more focused check, use Is GitHub down?, Is Claude down? or Is Cursor down?. The guide index covers the other tools.
Your next step should follow the smallest supported conclusion. Preserve work, stop repeated retries, give the team a clear update and verify the original operation after recovery. A status page is one useful signal. Your reproducible failure is another.