ASHR.work status
Availability and response times recorded by our own probe every 5 minutes, over the last 30 days.
Degraded performance
Recorded by our own probe every few minutes. Last recorded check 2026-08-21 04:40 UTC.
Public API
/api/v1/health
100.00% serving
334 checks over 30 days
- Latest check
- Degraded
- Availability target
- 99.90% (met)
- p95 response
- 125 ms (target ≤ 800 ms — met)
- Window coverage
- 3.9% · 28 days with no data
An HTTP request to the public API health endpoint, from the same region the app runs in.
Days with at least one failed or slow check: 2026-08-20, 2026-08-21.
Web application
ashr.work
100.00% serving
333 checks over 30 days
- Latest check
- Operational
- Availability target
- 99.50% (met)
- p95 response
- 107 ms (target ≤ 2000 ms — met)
- Window coverage
- 3.9% · 28 days with no data
An HTTP request for the site shell — it proves pages render, not that any signed-in screen works.
Database
Supabase Postgres
100.00% serving
333 checks over 30 days
- Latest check
- Operational
- Availability target
- 99.90% (met)
- p95 response
- 399 ms (target ≤ 1200 ms — met)
- Window coverage
- 3.9% · 28 days with no data
A single lightweight read against Postgres. It proves the database answers; it reads no tenant data.
How this page is measured
Our probe runs inside the same platform it measures, every 5 minutes. That means it cannot record a total outage of that platform: if everything is down, the probe does not run and no check is written. Those periods appear above as grey “no data” — never as green. We do not operate an independent external prober today.
Only the components listed above are measured. Other parts of the product — the Slack app, the MCP server, scheduled jobs, email delivery — are not probed and therefore have no row here. The MCP server in particular runs on your own machine and has no endpoint for us to check.
The targets shown are internal objectives and attainment is calculated from the recorded checks. They are not a service-level agreement, and nothing on this page forms part of a contract.
There is no automatic incident feed. Days that contain a failed or slow check are listed above from the recorded data; any written incident summary would be added by a person, and none are published here today. For anything affecting you, email support@ashr.work.
Figures refresh at most once a minute, and the “last recorded check” timestamp above tells you how current they are.
Building on top of ASHR.work? See the developer docs and the OpenAPI spec. For incidents, reach support@ashr.work.