A public readiness endpoint suitable for uptime-monitoring tools. No authentication is required. It verifies that the web application and its required database are reachable, without exposing connection details, account data, or exception messages.
Response shape
GET /v1/health.ashx HTTP/1.1
Host: javascriptobfuscator.com
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache, no-store
X-Content-Type-Options: nosniff
{
"ok": true,
"service": "javascriptobfuscator",
"version": "<assembly-informational-version>",
"uptimeSeconds": 12873,
"now": "2026-05-20T18:34:55Z",
"dependencies": { "database": "ready" },
"docs": "https://javascriptobfuscator.com/docs/healthendpoint.aspx"
}
ok is true only when the application can complete its bounded database probe. Database failure returns 503, ok:false, and dependencies.database:"unavailable". Results are cached in-process for 15 seconds to prevent monitoring traffic from becoming database load.
HEAD probes
Pingdom, BetterStack, and similar tools default to HEAD for cheap probes. The endpoint returns 200 OK with empty body on HEAD. Use HEAD over GET when you don't need the body and want to minimize bandwidth.
HEAD /v1/health.ashx HTTP/1.1
Host: javascriptobfuscator.com
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
What it does not reveal
Deliberate omissions, so the endpoint can stay public without auth:
- Database server, database name, connection string, driver exception, or query timing.
- Quota / billing state for any account.
- Request rates, latency percentiles, or any internal performance figure.
- Server hostname, container ID, or build infrastructure detail beyond the public assembly version.
- The set of optional features or providers enabled on the running deployment.
If you need any of the above, contact support — we can provision a token-gated endpoint scoped to a specific account.
Recommended monitor configurations
| Tool | Check type | Threshold |
| Pingdom |
HTTP, HEAD, expect 200, content match optional |
Alert after 2 consecutive 60s failures |
| BetterStack (Better Uptime) |
HTTP GET, expect "ok":true |
Alert after 1 failure; treat any non-200 as down |
| UptimeRobot |
HTTP keyword, expect javascriptobfuscator |
60-second interval |
| Datadog Synthetics |
API test, GET, assert $.ok = true and response time < 1000ms |
Multi-location (US/EU/AP) for geographic coverage |
What if the endpoint itself is the problem?
The handler deliberately avoids account, Stripe, PayPal, provider, and obfuscation work, but it does test the required SQL connection. A sustained 503 therefore means the application cannot currently perform normal account or protection work, even if cached marketing pages still load. Inspect application and database telemetry using the response timestamp; the public response intentionally omits internal failure detail.
Status page: aggregated uptime + incident history is on the
roadmap. Until it ships, the health endpoint plus whichever monitor you wire it into is the canonical source of truth.
Frequently asked questions
What does a successful health response actually prove?
That the web application is running and can complete a bounded probe against its required database. It is a readiness signal rather than a statement that every feature works, which is the right scope for an uptime monitor. If the database probe fails, the endpoint reports a service-unavailable status with the success flag false and the database dependency marked unavailable, so a monitor can distinguish an application that is down from one whose dependency is.
Do we need credentials to call it?
No, and that is deliberate. The endpoint carries no authentication so it can be pointed at by an external uptime service without provisioning a secret for it, which is precisely the situation where credentials tend to be handled badly. Everything that would make an unauthenticated endpoint risky has been deliberately left out of the response.
What is deliberately excluded from the response?
Anything useful to someone probing the deployment. There is no database server or name, connection string, driver exception or query timing; no quota or billing state for any account; no request rates, latency percentiles or internal performance figures; no server hostname, container identifier or build infrastructure detail beyond the public assembly version; and no indication of which optional features or providers are enabled. Those omissions are what allow it to stay public.
Should we use GET or HEAD for monitoring?
Use HEAD when you do not need to inspect the body, which is what most uptime tools default to. It returns a success status with an empty body and is the cheaper probe. Use GET when your monitor checks response content rather than status alone, which is the more precise configuration because it can distinguish a reachable application reporting a dependency failure from a healthy one.
Will frequent monitoring create database load?
No, because results are cached in the process for a short interval specifically to stop monitoring traffic becoming database traffic. Several monitors polling on a normal schedule will mostly be served from that cache. The practical consequence is that the endpoint reflects the state as of the last probe rather than the instant of your request, which is the correct trade for a readiness check.
How should we set alert thresholds?
Alert on consecutive failures rather than on a single one, so a transient network event between your monitor and the site does not page anyone. Two consecutive failures on a one-minute interval is a reasonable default for a status-only check. If your monitor inspects the body, treat a dependency-unavailable response as a distinct condition from no response at all, because they point at different problems and often at different owners.