What to do before reporting an app outage

"X is down." It's the most common report support teams receive, and it's almost always the least useful. A bare "X is down" tells the support team nothing about whether the problem is the service, the user's network, the user's account, the user's region, or a feature flag rolled out yesterday. The first response is always: "can you give us more detail?" — which is the question the report should have answered.

Five minutes of diagnosis before you report will do two things. First, it'll resolve the issue without a ticket about a third of the time, because the problem turns out to be on your end. Second, when the problem really is on the service's side, you'll have the timestamp, the error message, the screenshot, and the third-party confirmation that turns a vague complaint into the kind of report support teams act on within minutes.

This is the pre-flight checklist. Run through it before reporting. Skipping ahead is fine if you're confident, but each step earns its place.

Step 1 — Confirm it's not just you

The fastest filter. Test the service from a vantage point that isn't your current browser:

• Open the URL in an incognito or private window. This rules out cookies, cached state, and a misbehaving service worker.
• Try the URL on your phone over cellular data (not the same Wi-Fi). If it works on cellular, the problem is your home network — not the service.
• Run the URL through the Website Down Checker. It probes from our infrastructure. If it says the site is fine and you can't reach it, the problem is somewhere between you and the public internet — most likely your network or DNS resolver.

If all three of those tests say the site works, stop. The site is probably fine; something local is broken. See is it down for everyone, or just you? for the rest of the local-isolation walk-through. About a third of "app down" reports resolve here, and reporting an outage that's actually a local network issue wastes everyone's time — yours, the support team's, and other users who have a real problem and have to wait their turn behind your false positive.

Step 2 — Check the vendor's official status page

The second-fastest filter. Most major services publish a status page at status.<service>.com or <service>status.com. Open it.

If the page shows an active incident matching what you're seeing — you're done. The vendor knows, they're working on it, your report adds nothing useful. Don't file a ticket; subscribe to the incident updates and wait. Reporting a known incident to support during the incident generates noise that slows the team down without producing useful information.

If the page shows "all systems operational" but you're still seeing errors, three things might be true:

1. The status page is lagging. Pages typically lag real incidents by 5–60 minutes. If you've been seeing errors for less than 30 minutes, give the page time to catch up. See why official status pages sometimes lag.
2. The outage is partial. Status pages report at the component level. The top-of-page banner might be green while a specific component (say, voice servers in us-west) is degraded. Scroll down past the banner and read the component list.
3. It's an account-specific bug or feature-flag rollout. These don't show up on status pages at all because they don't trip global alarms. Your report is genuinely useful here — proceed to step 3.

Every service page on StatusDetector shows the vendor's official status alongside our own probe and recent user reports. The cross-reference is fast and saves you visiting three different URLs.

Step 3 — Capture the diagnostic evidence

Before doing anything else, capture what's happening. Memory is unreliable, error messages disappear when you reload, and once you've fixed the issue (or reloaded out of frustration), the evidence is gone. Capture first, debug second.

Minimum useful evidence:

• Exact timestamp (with timezone). Phone screenshots include the timestamp automatically; desktop screenshots usually don't. If you're going to file a ticket, note the time on a sticky note when you take the first screenshot.
• The exact URL that failed, including any query parameters. Copy from the address bar, don't paraphrase. Sensitive parameters (auth tokens, session IDs) you can redact.
• The verbatim error message. "Something went wrong" is not the error; it's the user-facing wrapper around the error. Open DevTools (F12 → Network tab), reload, click the failed request, copy the status code and the response body. For HTTP errors specifically, see what HTTP 403, 404, 429, 500, 502, and 503 errors mean for what each code actually says.
• A screenshot showing both the failed page and the URL bar. Browsers crop screenshots; a full-window grab is more useful than a clipped one.
• The output of the Website Down Checker for the failed URL. This gives the support team a third-party data point: "an independent probe at 14:32 UTC saw the same 502 you're reporting." It also surfaces the DNS, TLS, redirect chain, and registrar state, which often answers questions the support team would otherwise have to ask.

That's the minimum. The maximum, if you can capture it:

• Browser DevTools HAR file. A HAR (HTTP Archive) is a JSON record of every network request the browser made. It's the gold standard for "show me exactly what happened." In Chrome / Firefox / Safari, DevTools → Network → right-click any request → "Save all as HAR with content." Attach the HAR file to the ticket.
• Browser console output. DevTools → Console. Copy any errors. JavaScript exceptions, CORS failures, mixed-content blocks all show up here.
• The result of a curl -i to the failed URL if you're comfortable with the command line. This isolates the response from anything your browser might be doing — extensions, service workers, cached state.

Step 4 — Check whether others are seeing it

Useful for two reasons: (1) it tells you whether you're an isolated case or part of a wider incident, and (2) the volume of public reports often beats the status page as a leading indicator.

The places people actually go when something is broken:

• Down Detector — aggregates user-submitted "X is down" reports and plots them over time. A sharp spike is usually a real incident; a flat trickle is noise. The signal-to-noise ratio is good for major consumer services and poor for long-tail B2B ones.
• The service's subreddit or community Discord. r/ChatGPT, r/discord, r/github all light up during real outages within a few minutes of the incident starting.
• X / Twitter for "is X down" — fast but very noisy; the same complaint from 50 accounts looks the same as a real spike from 5,000. Filter to the past hour to find current reports.
• Hacker News for B2B and developer tools. The front page during a real incident usually has a thread within 15–30 minutes.
• The Shutdown Radar at StatusDetector. Merges third-party reports, our probes, and official feeds for every service in the catalogue.

If you see a clear public signal that the service is down, you don't need to file an individual ticket — the team knows. Subscribe to the incident updates if the vendor publishes them, and wait. If you're seeing it but no one else is, your report has higher value because you might be the first signal of an account-specific or feature-flag issue.

Step 5 — Write the report

If after the first four steps the service really does seem to be broken on its end, and the incident isn't already publicly known, write a useful report. Support teams triage by reproducibility — a report they can reproduce gets fixed quickly; a report they can't gets queued.

The template that works:

Summary. [What you were trying to do, in one sentence.]

What happened. [What the service did instead. Include the exact error message.]

When. [Exact timestamp with timezone.]

Where. [The exact URL or feature.]

Account / scope. [Your account ID, organisation, or anything that identifies which slice of the product is affected.]

Reproduction. [The smallest set of steps that triggers the issue. "Click X, then Y, then see Z."]

Evidence.

• Screenshot of the failed page (attached)
• HAR file (attached)
• Independent probe result: [link to /tools/website-down-checker result]
• Vendor status page at time of report: [linked]

Other observations. [Anything else useful — does it reproduce in incognito? On a different network? For a different account?]

A report in this shape gets actioned. A "your app is broken" message with no timestamp, no error message, and no reproduction steps gets a "can you give us more details?" reply and a 24-hour delay.

What not to do

A few common reporting anti-patterns:

• "Is X down?" comments on Reddit threads. These are not reports. They're emotional venting. No one with the power to fix the issue is watching the comments. If you want the vendor to know, file a ticket through the official channel.
• Mass-tweeting the company. Public companies notice this during major incidents but not minor ones. Sending eight tweets at @AcmeSupport will not move you up the triage queue and might get you flagged as a spammer.
• Reporting before the status page has had time to update. If the incident started 8 minutes ago, the page might catch up at minute 15. Reporting at minute 10 generates a duplicate of the inbound triage flood without adding information.
• Reporting only after the issue resolves. "It was broken from 14:00 to 14:30 yesterday" is essentially impossible to debug post-hoc. Real-time reports during the incident, with evidence captured during the incident, are an order of magnitude more useful.
• Filing multiple tickets for the same issue. A second ticket about the same problem doesn't move it up the queue; it just creates more triage work. Update the original ticket with new evidence.

A worked example

What a good report looks like in practice:

Summary. Cannot send messages in a specific Discord channel; all other channels work.

What happened. Send button greys out. Console shows POST to /api/v9/channels/.../messages returning 403 Forbidden with body {"message": "Missing Permissions", "code": 50013}. Same account can send in other channels in the same server.

When. 2026-05-12 18:22 PDT (started ~5 minutes earlier; no change to channel permissions on my end).

Where. Channel #general in server Example Inc (server ID 123456789012345678).

Account / scope. My user ID: 987654321098765432. Role: Admin.

Reproduction. Open Discord web (also reproduces on desktop). Navigate to #general in Example Inc. Type any message and click Send. Observe greyed-out send button and console error.

Evidence. Screenshot attached. Console log attached. Working in #random in the same server, same account, same browser — so this is channel-scoped, not user-scoped.

Other observations. Other admins in the same server report the same problem in #general but not elsewhere. Looks server-specific or channel-specific, not Discord-wide.

That report has a clear hypothesis (channel-specific permissions bug), the evidence to confirm or deny it (other admins see the same thing in the same channel), and the negative data that helps narrow it (other channels work for the same account). A support team can act on it.

The summary

Five steps, in order:

1. Confirm it's not local — incognito, cellular, third-party probe.
2. Check the status page — including the component list, not just the banner.
3. Capture evidence — timestamp, URL, error message, screenshot, HAR if you can.
4. Check public signal — Down Detector, subreddit, our Radar.
5. Write the report — template above. Include evidence. Avoid duplicates.

Steps 1 and 2 resolve about half of "broken app" cases without a ticket. Steps 3 and 4 take five minutes and double the speed at which a real ticket gets resolved. If you skip the prep work, you're not saving time — you're shifting it to the support team, who'll have to ask the questions you should have answered in the original report.

Frequently asked

The error message is just 'Something went wrong, please try again.' What do I include?

Open browser DevTools (F12), go to the Network tab, reload to reproduce, click the failed request, and copy the response body and headers. That's the real error message — the user-facing wrapper is just the app's polite version. Status code and response body together usually identify the cause.

Should I tweet at the company instead of filing a ticket?

Generally no. Tweets are public, often visible only to the marketing team, and provide a worse channel for attaching evidence (screenshots, HAR files, logs). The exception: for major consumer outages, a single tweet sometimes accelerates acknowledgement because it amplifies the issue. For B2B or account-specific issues, always file through the official support channel.

What if I don't have access to DevTools or a HAR file?

Send what you can. A clear screenshot, the URL, the timestamp, and a description of what you clicked is enough for support to investigate. The fancy diagnostics are optimisations — the basic five fields (summary / what / when / where / reproduction) are what they really need.

How long should I wait for a response before escalating?

Depends on the vendor and your tier. For paid B2B SaaS with an SLA, the SLA is the contract — typically 4–8 business hours for first response. For consumer products without an SLA, 24–48 hours is normal. Escalating before then ("any update?") slows triage; the support team is balancing many tickets at once. Re-escalate only if you have new evidence or the SLA window has clearly elapsed.