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.