Our public status page is now live at status.302.sh. It brings service availability, response trends and incident history into one place, so you have somewhere to look when a link, dashboard or report is not behaving as expected.
A short link on a printed sign or in a scheduled email may need to work long after you last opened the dashboard. When something goes wrong, the first useful question is simple: does the problem affect one link, or a wider part of the service? We built this page to help you answer that question.
Six services, one place to check
The page separates the parts of 302.sh you use. Loading the dashboard, following a short link and querying analytics are different operations; the status of each deserves its own row.
| Service | What the check covers |
|---|---|
| Short links | A representative shared-host redirect, its expected destination and that destination's availability. |
| Dashboard | Delivery of the dashboard page and its page-specific JavaScript. |
| Public API | A public JSON endpoint, including a real database read. |
| Custom domains | Domain configuration and representative certificate readiness. |
| Analytics | Analytics configuration and availability of the query service. |
| Bio pages | Availability of the public Bio page renderer. |
Each row describes its coverage on the live page. These are service checks with a defined scope: they do not exercise signed-in dashboard actions, API writes or Bio publishing. The domain check does not test every customer's DNS and TLS, and the analytics check does not verify click ingestion or every report.
Start with the latest report time
Checks are scheduled once a minute, and the page retrieves updates automatically. The Reported timestamp tells you when the latest checks finished. The Refresh button retrieves the latest completed report; it does not start a new check.
If that report is more than five minutes old, the page says Live report delayed. If a valid report cannot be retrieved, it says Live report unavailable. Recorded history stays visible so you can still review it, while the message makes the gap in current information clear.
Explore the history we have actually observed
Choose a 30, 60 or 90-day view to explore daily availability. Hover over a day, or focus the history and use the arrow keys, to read its details. Dates and incident timestamps use UTC, so people comparing the same event have a common reference.
History starts with real monitoring observations. At launch, a 90-day view will naturally contain days with no data. Those days stay gray. The uptime percentage uses observed minutes only and excludes minutes recorded as outages; degraded performance is shown separately. A gap in monitoring is not evidence that the service was available.
The Response time chart adds a view of short-link HTTP checks over the previous 24 hours, with an average and 95th percentile. These timings include destination validation. Use them to understand the monitor's observations; your visitors' locations, networks and destination pages can produce different experiences.
Follow detection and recovery
The Incident history section records affected services and timestamped updates. Expand an incident to see its timeline. Automatic entries describe when a problem was detected and when recovery was observed, giving you a record you can compare with your own experience.
The Download history button exports the incident record as JSON if you want to keep a copy for a campaign review or support request. It exports incidents, rather than the availability bars or response-time samples. Light and dark themes make the page comfortable to keep open alongside your other tools.
If one link still does not open
Start with the report time, the affected service row and any incident timeline. If the observations are current and no matching incident is shown, check the individual link's destination and settings next. A destination can move, and an owner-set expiration or click limit can stop a particular link. Our guides explain link expiration and why a printed QR code can stop working.
If you need help, keep the affected URL, the time and time zone, the error you saw and whether it happens on another network. Share private link details through support rather than posting them publicly.
The status page runs separately from the main application, with its own deployment and monitoring store, and does not require the app's login or analytics scripts. Both its hosting and checks use Cloudflare, so it still shares that provider's platform. That matters when interpreting a wider provider outage.
Keep the status page close
Visit status.302.sh and bookmark it before your next campaign. You can also find the Status link in the 302.sh footer. There is no account to create and no dashboard to sign into.
Short links are often the smallest part of a campaign, but people depend on them to reach everything else. The new status page gives you a place to check what we can observe, see when something changed and follow its recovery.