Documentation

Guides for protecting production JavaScript

Reference guides for release workflows, command-line usage, cross-file protections, and the desktop app.

Inside The Docs

Practical guides, not placeholder pages.

How-to guides Start with release sequencing and command-line usage, then move into feature-specific references.
Advanced protection Browse cross-file controls like Replace Globals and Protect Members when a build spans multiple scripts.

Health endpoint

  • https://www.javascriptobfuscator.com/v1/health.ashx
  • None
  • GET, HEAD (others → 405)
  • Never — Cache-Control: no-cache, no-store

A tiny public health-check endpoint suitable for uptime-monitoring tools. No authentication required, so a monitor doesn't need to manage JSO API credentials. Reveals nothing sensitive — not SQL connectivity, not quota state, not request rates — only service liveness.

Response shape

GET /v1/health.ashx HTTP/1.1
Host: www.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",
  "docs": "https://www.javascriptobfuscator.com/Docs/WireFormat.aspx"
}

ok is always true when the service is up; an unhealthy server typically wouldn't return at all, so monitors should treat HTTP-level failures (timeouts, 5xx) as the real health signal, with "ok": true as a corroborating sanity check.

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: www.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:

  • SQL connectivity status (a future /v1/health/db can carry this, gated behind a token).
  • 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 features 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

ToolCheck typeThreshold
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 is independent of every other part of the site — no database, no API key checks, no Stripe / PayPal calls, no obfuscation pipeline. If /v1/health.ashx is failing while the rest of the site works, that's almost certainly an infrastructure problem (load balancer rule, WAF, edge cache) rather than a JSO problem. Treat sustained /v1/health 5xx with the rest of the site green as a routing issue, not a service outage.

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.