Enter a public URL → HTTP status, pass/fail, and latency. Honest smoke test from our server — not full uptime monitoring.
Checks from our infrastructure, single location. Public URLs only.
This tool sends one HTTP request from our server to the URL you enter. It reports the status code, whether we consider the site reachable, and response latency in milliseconds. That answers a narrow but common question: “From outside my network, does this URL respond right now?”
It is not uptime monitoring. Real monitoring runs continuously from multiple regions, alerts on-call, stores SLA history, and pages you at 3 a.m. We run one check, from one place, when you click.
Developers often test from office VPN or localhost. Customers use different ISPs, DNS resolvers, and continents. An external smoke test catches “works on my machine” gaps — especially after DNS cutovers, CDN changes, or firewall updates.
After deploying https://app.example.com/health, you get 200 in 142 ms → UP.
Action: proceed with smoke tests on API and SSL. No monitoring substitute — schedule synthetic checks separately.
Checker returns 403 in 45 ms; your browser gets 200.
Likely cause: bot protection blocking datacenter IP ranges. Fix: allowlist monitor IPs in WAF or use official health endpoint policy.
Checker: timeout or connection error. You recently changed A record.
Run DNS Analysis — old IP may still appear from some resolvers during TTL propagation.
Latency here is server-side round trip to first response — not Largest Contentful Paint or Time to Interactive. Sub-200 ms often indicates healthy origin from our region; above 1000 ms warrants investigation but is not automatically an outage if status is 200.
Each step adds cost and complexity — climb when incident frequency or contract requirements justify it.
This checker uses HTTP(S). A host can respond to ping while nginx is down, or vice versa if ICMP is blocked. Match check type to user experience — customers care about HTTP for web apps.
If this checker flaps UP/DOWN while real monitoring is stable, suspect WAF bot scores, geo blocking, or rate limits on health endpoints. Fix monitor allowlisting before on-call mutes alerts globally.
For SLA reporting, define “up” consistently: HTTP 200 within 5 seconds from at least three regions for 99.9% — this single check is step zero, not the report.
Pair availability with business hours weighting for internal reviews: night failures matter less for B2B weekday products but matter enormously for consumer global apps — context changes priority even when minutes are equal.
Prefer checks on user-critical URLs (login, checkout, public API health) not only marketing homepage cached at CDN. Set timeout thresholds aligned with SLA — if 5s is failure internally, do not cheer 4.9s smoke test as healthy without trend context.
IPv6-only hosts may behave differently from dual-stack — if AAAA records exist, validate both address families in production monitoring; this HTTP check follows resolver behavior on our server.
One probe cannot prove monthly uptime, but you can use the same math vendors use to sanity-check claims. For period minutes P and downtime minutes D, achieved uptime = 100 × (1 − D/P). At 99.9% over 30 days (43,200 minutes), allowed downtime ≈ 43.2 minutes. A single 52-minute outage you just verified externally would breach that budget — but only continuous monitoring proves D. Use our Allowed Downtime Calculator and Error Budget Calculator for full-period math; this checker supplies one data point, not the ledger.
/health or login may still be down.Contract: 99.95% monthly on public API. March = 31 days = 44,640 minutes. Allowed downtime = 44,640 × 0.0005 ≈ 22.3 minutes.
You confirmed two external failures via this tool: 14 min + 11 min = 25 min total (timestamps in ticket).
Achieved ≈ 100 × (1 − 25/44,640) = 99.944% — below promise. Next: independent monitor export for claim pack, not another single click here.
Single location, single moment, HTTP GET semantics only. No auth headers, no WebSocket, no TCP-only services, no certificate validation beyond what the HTTP client performs. Results may differ from browser experience (cookies, JavaScript redirects, geographic routing). This is triage — not monitoring.
This sequence takes 5–10 minutes manually — faster than debating whether the outage is “real” without external confirmation. Document results with UTC timestamps in the incident channel for post-mortem timeline.
HTTP 502/503/504 often indicate gateway or upstream failure — check origin health even when CDN reports issues. HTTP 429 suggests rate limiting — retry once after 60 seconds before escalating. Connection timeout with no status code may be DNS, firewall, or complete origin failure — run DNS and SSL tools next. Document exact status code and latency in incident ticket; “site down” without numbers slows post-mortem.
When external check confirms DOWN, update Status Page within comms SLA. When check shows UP but social reports continue, note “external probe PASS at HH:MM UTC” in status banner — transparency about monitoring limits builds trust vs silent green page during ambiguous degradation.
B2B customers sometimes ask for third-party uptime proof during their own incident. A single check screenshot with UTC timestamp can supplement — but not replace — your SLA report export. Label it “ad-hoc external smoke test” so nobody mistakes it for contractual monitoring data.
SSL Certificate Checker · DNS Analysis · Speed Smoke Test · Business impact: Downtime Cost · Reliability Money Toolkit · Free Tools.
No. One HTTP request from our server in one location. Use for spot checks, not SLA proof or on-call paging.
Typically 2xx and often 3xx. 4xx and 5xx show as not OK from our vantage point.
Geo blocking, WAF, bot detection, or IP allowlists can block our server while your browser succeeds.
No account required. URLs are sent to our check API for the request only.
Only public URLs reachable from the internet. VPN-internal hostnames are not accessible.
Round-trip milliseconds from our server until HTTP response headers arrive — not browser Core Web Vitals.
Use multi-region monitoring with exported logs for disputes. This single check is a sanity test only.
Try SSL Checker, DNS Analysis, REST API Checker, or Speed Smoke Test for layered diagnosis.