A small in-page status widget. Hitting this page starts a 10-second-interval poll of the JSO health endpoint and shows the result. Useful when you want a glance at "is JSO up right now" without leaving the docs.
Checking…
- Endpoint
- /v1/health.ashx
- Last check
- —
- Round-trip time
- —
- Reported version
- —
- Reported uptime
- —
All metrics here come from in-browser observation. JSO doesn't see this page's polling traffic differently from any other client of /v1/health.ashx.
Recent checks
Last 20 results. Cleared on page reload.
| When |
Status |
HTTP |
RTT |
| No checks yet — the first one runs in a moment. |
If the widget says FAIL but the site loaded
The readiness endpoint checks both the ASP.NET application and its required database. Cached marketing HTML can therefore load while account, payment, or protection work is unavailable. A sustained 503 is an actionable service failure; inspect application and database telemetry. A browser-only network error can also indicate a CDN, WAF, or routing problem. See the health endpoint runbook for the exact response contract.
Reading the round-trip time
The RTT shown here is measured in your browser with performance.now() around a single fetch, so it includes everything between you and the origin: DNS, TLS, your own network, any CDN or WAF hop, and the application’s own work. It is a useful smell test and a poor benchmark.
What to read into it:
- A stable number, whatever its value. Consistency matters more than magnitude. A steady 300 ms from a distant region is healthy; a figure oscillating between 40 ms and 4 s is not.
- A step change while the page is open. Because the poll runs continuously, a sudden shift is more informative than any single reading — you have a before and an after from the same client.
- OK with a rising RTT. Often the earliest visible sign of a saturated dependency, before anything starts returning errors.
What not to read into it: this is one client on one connection. A slow reading here is at least as likely to be your network as ours, which is why the comparison worth making is against your own baseline rather than against an absolute target.
What this page is not
It is a live probe, not a status page and not a historical record. The last 20 results are held in memory and cleared on reload — nothing is stored, and no result from your session is reported back to us. If you need history, alerting, or an incident timeline, run the same check from your own monitoring rather than leaving this tab open.
It also checks one endpoint. A green result means the application and its database answered a readiness probe; it does not exercise protection, billing, or the dashboard. A protection request can fail for reasons this probe cannot see, and when it does the response body from the API itself is a better diagnostic than anything on this page.
Wiring this into your own dashboard
Everything this page does, your monitoring tool can do without us:
curl -fsS https://javascriptobfuscator.com/v1/health.ashx \
| jq -e '.ok == true and .uptimeSeconds > 0'
The health-endpoint doc has Pingdom / BetterStack / UptimeRobot / Datadog Synthetics templates.
Frequently asked questions
What is this page actually polling?
The readiness endpoint, once every ten seconds for as long as the page is open. Everything shown is measured in your own browser, and the last twenty results are held in memory only. We do not see this page's polling traffic any differently from any other client of the same endpoint, which means what you are reading is your view of the service rather than ours.
The widget reports a failure but the site loaded for me. What does that mean?
That the parts of the service you touched are not the parts the probe checks. The readiness endpoint tests the application together with the database it depends on, so cached marketing pages can render perfectly while account, payment and protection paths are unavailable. A failing probe against a page that loaded is therefore a meaningful signal rather than a contradiction, and it points at the paths that need a real request to test.
How should I read the round-trip time?
As a measurement of everything between you and the origin, not of the service alone. It is taken in your browser around a single request, so it includes name resolution, connection setup, the network path and any intermediary, along with the time the application spent. That makes the absolute number much less informative than its behaviour over time.
What is worth reading into a change in that number?
Three patterns. A stable figure of any magnitude is healthy, since consistency matters more than size and a steady reading from a distant region is fine. A step change while the page is open is the most informative thing here, because a continuous poll gives you a before and after. And a healthy result with a steadily rising time is often the earliest visible sign of a dependency under strain, arriving before anything starts returning errors.
Is this a status page?
No, and the distinction matters when something is wrong. It is a live probe from one browser on one connection, with no history, no storage and no aggregation, and it checks a single endpoint. A healthy result means the application and its database answered a readiness request; it does not exercise protection, billing or any other path. Read it as one data point you generated, not as a statement about the service.
How do I wire the same check into our own monitoring?
Request the same endpoint and assert on the response body rather than only on the status code, checking that the readiness flag is true and that uptime is positive. Anything your monitoring tool can schedule will do it, and the health endpoint documentation carries ready-made templates for the common services. Running it from your own infrastructure is strictly better than watching this page, because it keeps a history and it can wake somebody up.