Availability Check
Purpose
Quickly verify whether your shop website or any specific URL is reachable. The Availability Check returns HTTP status, response time, headers, body length (optional), and any errors encountered so you can triage downtime, redirects, or misconfigured servers.
🧭 What this feature shows
Checked URL — the exact URL requested.
Request method —
HEAD(fast, headers only) orGET(includes body length/behavior).HTTP status — numeric status code and an intuitive badge (success / redirect / client error / server error).
Response time — measured round-trip time in milliseconds.
Headers — all response headers captured (displayed key → value(s)).
Body length — number of bytes if
GETwas performed.Error messages — timeouts, DNS failures, TLS errors, CORS or connection refused info.
Checked at — timestamp for the run and a short human summary.
👥 Who should use this
Shop owners verifying site uptime after deploys or DNS changes.
Support and ops teams diagnosing downtime, redirects, certificate problems, or slow backends.
Developers validating CDN, load balancer, or proxy responses.
SEO/marketing teams confirming correct HTTP responses for crawlers and bots.
⚙️ How it works (high level)
Input URL — operator supplies the URL to check (defaults to shop website if available).
Choose method —
HEADfor quick header-only checks,GETfor full response behavior and body length.Server-side request — the application performs the HTTP request from the server environment with safety timeouts and limited redirects.
Collect measurements — measure timing (ms), record status, capture headers, and capture body length (for GET).
Store & present — results are stored as a check record and shown in a detail view with header table, status badge, and optional PDF export.
🪜 How to use — step-by-step
Navigate: Dashboard → Availability Checks → Run New Check.
Enter or confirm the target URL (the shop’s website is prefilled if available).
Choose request method: HEAD (fast) or GET (more details).
Click Run Check.
After the check completes, open the check’s Details page to view the status badge, response time, headers, body length, and summary.
Click Download PDF to export the result for reporting or audits.
📊 How to interpret results (actionable guidance)
200–299 (Success) — the URL is reachable. Confirm the expected content/headers are present.
300–399 (Redirects) — follow-up may be needed; check
Locationheader to ensure redirect target is correct.400–499 (Client errors) — resource missing/forbidden; verify path, auth, or bot blocking (e.g., WAF).
500–599 (Server errors) — backend problems; check application logs and upstream services.
Response time high — investigate slow queries, backend timeouts, or network latency.
Unexpected headers — e.g., missing
cache-control, wrongcontent-type, or security headers (CSP, HSTS) absent — update server config.Body length zero on GET — server may return an empty body (check for 204) or truncated output due to errors/timeouts.
✅ Recommended actions (prioritised)
Status 5xx — check server logs, restart services, verify upstream dependencies (DB, cache).
Status 4xx — if legitimate users should access the page, check authorization, file existence, and routing rules.
Unintended redirect loops — inspect
Locationheader chain, and verify canonical URL and proxy config.Slow response times (>500–1000ms) — run profiling on server, database, and check network path.
Missing security headers — add/enable
Strict-Transport-Security,Content-Security-Policy,X-Frame-Options,Referrer-Policy, etc.DNS/TLS errors — verify DNS records, SSL certificate validity and chain, and intermediate certs.
📤 Exporting & reporting
Download PDF — export a printable report of the check (headers, status, timings, errors) from the detail view.
CSV / Bulk reporting — for many checks, export the index to CSV (if implemented) with columns:
checked_at, url, method, status, timing_ms, body_length, summary.Integrate alerts — optionally wire failed checks into email/Slack or webhook alerts for immediate ops notification.
🗓️ Recommended cadence
After deployments or DNS changes — run immediately and again after propagation (~24 hours).
Post-incident verification — validate fixed endpoints before closing incidents.
Routine — daily or weekly monitoring depending on how critical the site is. For mission-critical services, consider more frequent automated checks and alerting.
🔒 Privacy & safety notes
Checks are performed from the server — they only access publicly reachable URLs.
The tool may store the URL and headers in the checks table; avoid storing sensitive tokens/credentials in the URL or querystring.
If a URL requires authentication, use a dedicated, secure internal check flow (do not embed credentials in public checks).
Respect robots and legal considerations when scanning third-party domains.
🧩 Troubleshooting & FAQs
Q: The check times out before returning a result. A: The server enforces timeouts to avoid hangs. Increase timeout carefully (developer-side) or investigate network/DNS issues or slow backend.
Q: I ran a GET but the body is truncated. A: Server-side request may hit a size limit or the remote closed early. Check request/response size limits and intermediate proxies.
Q: The headers show Cloudflare or CDN values I didn't expect. A: The request originated from your server; CDN or reverse proxy in front of the origin may apply their own headers. Compare with client-side responses and CDN config.
Q: The check shows 200 but page looks different in a browser. A: Check for conditional responses (user-agent rules), geo-based content, or authentication gates. HEAD/GET from server may not replicate browser cookies or JS behavior.
Q: Can I schedule checks or monitor alerts? A: The UI is interactive. For scheduled monitoring, implement a background job or cron to run checks and trigger alerts when thresholds are breached.
✅ Quick checklist
Last updated