Hit an API endpoint with GET or POST. See status code, latency, and whether it matches your expected response.
Public endpoints only. No auth headers — use for health checks and open APIs.
Health endpoints (/health, /ready, /live, /status)
exist so automation can ask “is the API process up?” without executing full user journeys.
This checker sends one GET or POST from our server and compares the HTTP status code — optionally
against your expected value.
Free tool, no signup. Honest scope: not API monitoring, not contract testing, not load testing.
URL: https://api.example.com/ready · Expected: 200 · Result: PASS in 89 ms
Interpretation: load balancer path healthy from internet. Does not prove database migrations succeeded.
Some apps return 503 on /health when dependency down (fail-visible pattern).
Set expected status 503 during maintenance validation; default 2xx-only pass would misleadingly FAIL.
/health → 200. /v1/checkout → 500 for all users.
Lesson: add synthetic checks on critical business paths in proper monitoring; smoke test is floor not ceiling.
Good /health returns 200 when critical dependencies are reachable — not always when
every optional subsystem is up. Split /live (process up) and /ready (can serve traffic)
for Kubernetes. Document which endpoint this checker hits in runbooks.
Run curl from CI after deploy; this page is for ad-hoc human checks from outside your VPC when CI green but customers report issues — different network path, same idea.
APIs behind API keys or JWT often return 401 to unauthenticated probes — expected, not “down.” Create dedicated unauthenticated health routes or use this tool only on public endpoints designed for anonymous checks.
GraphQL single endpoint may return 200 with errors array in body — this checker sees HTTP layer only.
For GraphQL, extend monitoring in application tests that parse errors field.
Rate limiting can return 429 during aggressive CI; this tool sends one request — if 429, distinguish throttling from outage before paging.
| Tool | Best for | Limitation |
|---|---|---|
| This checker | Quick external GET/POST status from browser | No auth, one location, no body |
| curl | Scripted checks with headers from your laptop | Your network path, not customer path |
| Postman | Collections, auth, assertions | Manual or Newman CI setup required |
| Production monitoring | 24/7 multi-region with paging | Cost and configuration time |
Use this page when you want a shareable “external check failed at 15:04 UTC” screenshot for a war room without installing CLI tools on a support laptop. Escalate to CI and monitoring for permanent coverage.
HTTP status alone ignores response body contracts. An API returning 200 with {"status":"fail"}
still breaks clients — follow with application tests. Latency shown here is one sample; cold starts and
TLS negotiation can skew first request — run twice if borderline.
REST smoke tests answer: “Did the server return the expected status code for this URL from outside?” Define pass criteria in runbooks before incidents. Common patterns: 200 = healthy, 503 = unhealthy but reachable (Kubernetes readiness), 401 = auth required (not necessarily down). Latency pass threshold example: fail if > 2000 ms for three consecutive external checks — this tool gives one sample; multiply manually or use monitoring for consecutive logic.
{"status":"degraded"} — HTTP layer only.URL: https://api.example.com/v1/health · Expected: 200.
Baseline (last week): PASS in 95 ms, 102 ms, 88 ms (internal monitoring).
Today external check: PASS in 2,340 ms — still 200, but 22× slower than baseline.
Action: treat as degradation incident; open ticket before customers timeout at 3s client SDK limit. Full outage avoided; SLA latency SLO may still breach.
GET and POST without body, headers, or cookies. Single request from one datacenter. No GraphQL body parsing, no gRPC, no WebSocket upgrade checks. Cannot reach private RFC1918 hosts. Not a substitute for contract tests, schema validation, or load testing — a fast external sanity layer only.
External API check FAIL on /health during business hours often warrants SEV2 declaration if no workaround. PASS with latency 3× baseline may be SEV3 degradation — log in incident channel even without page. Document expected status codes per environment in runbook: staging may intentionally return 503 when dependencies are down for chaos tests — do not page production on-call with staging URL.
After firewall or WAF change tickets close, run this checker on three URLs: public health, one authenticated business path (expect 401 — confirms reachability), and admin path (expect 403). Pattern confirms policy applied without accidental block of legitimate monitor paths.
Tag each deploy with version header or /health body field when possible. When external check fails after deploy #8842, rollback decision is faster than binary search across six hours of commits. This tool cannot read response body — but HTTP status flip from 200 to 500 immediately after deploy timestamp strongly implicates release; note deploy ID in incident channel alongside checker result screenshot.
If contract defines API availability as successful 2xx on /health from external probe, one failed check does not breach monthly SLA — but 72 failed minutes in a 43,200-minute month = 99.83% achieved. Use continuous monitoring for vendor disputes; this checker validates “right now from outside” during active triage. Pair with Reliability Money Toolkit for customer-facing SLA math separate from vendor credits.
Payment and partner webhooks often use POST with signed payloads — this tool cannot validate signatures.
For webhook reachability only, some teams expose unauthenticated /webhook-health returning 200.
Document which endpoints are safe for anonymous external checks vs which must stay in CI with secrets.
OAuth login flows, file uploads, and idempotent PUT operations need CI integration tests — not browser smoke checks. Use this page at step zero when users report “API down” to confirm external TCP/TLS/HTTP path before diving into distributed traces. Saves 15–30 minutes when issue is WAF block vs application bug.
Paste checker output into incident timeline: URL, method, status code, latency ms, UTC timestamp, PASS/FAIL. Post-mortem readers six months later should reconstruct external perspective without re-running tools. Link to Post-Mortem Generator after resolution.
Availability Checker · Speed Smoke Test · Downtime Cost · Free Tools.
No. GET and POST only, empty POST body, no custom headers. Use Postman or CI for authenticated tests.
Quick verification that a public health endpoint returns expected HTTP code from outside your network.
/health may return 200 while business endpoints fail. Smoke tests prove one URL only.
No. Single request from our server.
Optional field — if blank, 2xx passes. Some health endpoints return 503 when unhealthy by design.
No. URL must be reachable from the public internet.
POST sends an empty body. JSON APIs requiring payload will not work here.
Verify DNS, SSL, availability; inspect logs; confirm WAF; run full integration tests in CI.