API health
This page checks the yas.sh /api/health endpoint and reports the result as measured from your region. It reflects a point-in-time check, not a formal uptime SLO.
This page reflects the status of the /api/health endpoint as measured from your region at load time. It is not an uptime guarantee, and no uptime percentages or latency benchmarks are displayed because those have not been published with a reproducible methodology.
GET /api/health. The public payload is liveness only. For support or incident questions, use Contact.About this status page
This page reports the current operational state of the YAS.SH platform: the API, the redirect service that resolves short links, the tools that execute server-side, and the monitoring workers that run scheduled checks. It exists so that when something is wrong you can confirm it here rather than inferring it from a failing request.
Short-link redirection is treated as the highest-severity component. A broken redirect breaks links that other people have already published on materials we do not control — printed items, emails already delivered, third-party pages — so it is engineered and prioritised differently from the rest of the platform.
What each component covers
Redirect service
Resolution of short links to their destinations. The most critical path, because failures affect links already in circulation.
API
The REST endpoints for links, tools and account operations, including authentication and rate limiting.
Server-side tools
Tools that execute on our infrastructure — DNS, TLS, HTTP and mail-authentication checks. Browser-based tools keep working regardless of this component.
Monitoring workers
The scheduled scanners that evaluate your domains and raise alerts on verdict changes.
How incidents are handled
An incident is opened when a component is degraded or unavailable, not only when it is completely down — partial failures affecting a subset of requests are the more common case and are the ones most likely to be misdiagnosed as a problem on your side. Updates are posted as the situation develops rather than only at resolution.
After a significant incident we publish what happened and what changed as a result. The useful part of a post-mortem is the change, not the apology, so that is what we lead with.
If something looks broken and this page says everything is fine
Check whether the failure is specific to your network or region first: DNS resolution, a corporate proxy, or an ad blocker interfering with page assets account for a large share of reports. The tools on this site can help — the DNS Lookup and HTTP Header Viewer run from our infrastructure, so comparing their result with what you see locally isolates the difference quickly.
If the problem persists, report it through the contact page with the time, the URL and what you observed. A report that includes the exact timestamp is worth several that do not, because it can be matched against logs.
Frequently asked questions
Does this page update automatically?
Component states reflect current checks. During an incident, written updates are added as the situation changes rather than only when it is resolved.
Do browser-based tools stop working during an outage?
No. Tools that run entirely in your browser keep working once the page has loaded, because they do not call our infrastructure. Only server-side tools are affected.
What happens to my short links if the platform is down?
Redirect resolution is the most critical component and is prioritised accordingly during any incident. It is also the component we would restore first.
How do I report a problem that is not shown here?
Use the contact page and include the timestamp, the URL and what you saw. Security issues should go through the channels in our security.txt instead, so they are triaged as security reports.