Methodology - How SiteDownCheck Checks Work

How to read this page

This page explains how checks run, family by family, so you can judge whether a result applies to your situation. Exact timeouts and thresholds may be tuned over time, so we describe behaviour rather than promise fixed numbers. Corrections: contact@sitedowncheck.com, see the editorial policy.

Where checks run

Checks are made from SiteDownCheck's own servers. Unless the operator has configured extra probe servers, there is one vantage point. Each result reflects what that location observed at that moment, over that network path. It is not a global view of your site.

Before connecting, the service validates the target. Private, loopback, link-local and other internal addresses are refused, both when you enter an IP and when a hostname resolves to one. HTTP-based tools only connect to ports 80, 443, 8080 and 8443. The port checker uses its own allow-list. Rate limits apply per visitor, and some results are cached briefly (see limitations).

Availability tools

Resolution and connection

A check starts with DNS resolution of the hostname, using the system resolver, and records how long it took. It then opens a TCP connection to the chosen port and records connect time. For HTTPS, a TLS handshake follows, and the certificate is validated against the trust store used by the server. If any stage fails, the result names the stage, for example "DNS lookup failed", "connection refused", "connection timed out" or "TLS handshake failed", because these point to different causes.

Deciding whether a site is up

The HTTP status check sends a request and classifies the outcome:

The reasoning for the access-restricted category is that the server answered. A 403 or 429 often means a firewall or rate limiter is declining our request, which says little about whether real visitors can load the page. A 404 or 410 on the address you entered is treated as down because the page you asked about is not being served.

Monitors add one more rule. A failure must be confirmed twice before an alert is sent, which filters out a single dropped packet or a brief restart.

Redirects

The redirect checker and debugger follow redirects manually, one hop at a time, up to a maximum of 10 hops. For each hop it records the status code, the Location header and the timing. It detects loops by tracking URLs already visited and stops as soon as one repeats. It flags common problems such as HTTP to HTTPS to HTTP bounces, mixed www and non-www chains, and redirects that drop the path.

Response time

Two figures are reported where available. Total time is measured from the start of the request until the response body is fully received. Time to first byte (TTFB) is measured from sending the request to receiving the first byte of the response, and includes server processing but, in our reports, is shown alongside DNS, connect and TLS phases so you can see where the time goes. A single reading is a sample, not a benchmark; the monitor chart shows the trend.

Root-cause and maintenance tools

The outage root-cause finder runs several checks in sequence (DNS, connect, TLS, HTTP, headers) and reports the first stage that fails, with likely causes. The Cloudflare error checker and maintenance-versus-outage tool interpret status codes, headers and page signatures. These are heuristics.

Health and speed

The health check combines availability, certificate, DNS and header signals into a summary. Core Web Vitals and performance scores come from the Google PageSpeed Insights API, so those numbers are Google's lab and, where available, field data, not our own measurements. Page weight counts the bytes of the main document and discovered resources. The broken-link checker requests links found on a page and reports status codes, with a cap on how many it follows. Robots.txt and sitemap tools fetch and parse the files and report syntax issues and unreachable URLs.

Security tools

SSL and TLS

The SSL tools connect, perform a handshake and read the certificate chain. They report subject and SAN names, issuer, validity dates, days remaining, key type and size, and signature algorithm. They validate that the hostname matches, that the chain builds to a trusted root, and that no certificate in the chain has expired. A missing intermediate certificate is reported separately because some browsers fetch it automatically and others fail. The TLS version tool attempts handshakes with each protocol version and reports which are accepted.

Security headers and HSTS

The security header check requests the page and inspects headers such as Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options (or CSP frame-ancestors), Referrer-Policy and Permissions-Policy. Scoring is checklist-based: each header is present or absent, then checked for obviously weak values, for example a CSP containing unsafe-inline without nonces, or an HSTS max-age that is short. The score shows hygiene, not security. HSTS checks also look for includeSubDomains and preload directives.

Blacklist (DNSBL)

The blacklist tool resolves the target IP, reverses its octets, and queries each configured DNS blocklist zone. An answer in the 127.0.0.0/8 range means listed, and NXDOMAIN means not listed. Some lists return error-style answers when a resolver is over quota, and those are reported as "could not check", not as clean.

DNS and domain tools

DNS lookups query the record types you request and show answers, TTLs and the resolver path used. NS tools compare answers from each authoritative server, so inconsistency between servers is visible. DNSSEC checks look for DS records at the parent and DNSKEY and RRSIG records at the zone, and report whether the chain validates.

SPF, DKIM and DMARC

The SPF checker parses the record and counts DNS-querying mechanisms (include, a, mx, ptr, exists and redirect) recursively. RFC 7208 allows a maximum of 10 such lookups, and exceeding it produces a permanent error that can break authentication. Records with more than one SPF TXT record at the same name are flagged. DMARC checks parse the policy, alignment and reporting tags. DKIM checks query selector._domainkey names for selectors you supply or common ones, since DKIM selectors cannot be listed. Email deliverability is an assessment of DNS configuration, not a test of delivery to inboxes.

WHOIS and RDAP

Domain registration data is requested over RDAP, the structured protocol that replaced much of WHOIS, using the registry service found through the IANA bootstrap. If RDAP is unavailable for a TLD, the tool falls back to a port-43 WHOIS query. Many registries redact personal contact data, so absent registrant details are normal. Domain age and expiry come from the creation and expiration events returned.

Subdomains and history

The subdomain finder uses certificate transparency logs through crt.sh. It can only find names that appeared on publicly logged certificates, so it is incomplete by design, and wildcard certificates hide individual names. DNS history reflects the data sources available and may have gaps.

Hosting and network tools

IP lookup and hosting detection combine reverse DNS, registry allocation data and ASN information. ASN lookups use Team Cymru's DNS-based service. Reverse IP lists hostnames known to be associated with an address from available data, which is never complete on shared hosting. The CDN detector infers a CDN from response headers, CNAMEs and IP ownership, so a CDN that hides these signals may not be detected.

Browser-only developer tools

The JSON, Base64, URL, JWT, timestamp, regex and QR tools run in your browser. Their input is not sent to our servers. The JWT decoder reads the token but does not verify a signature unless you provide a key, so a decoded token is not proof of validity.

Monitoring methodology

Monitors run the check you configure at your chosen interval, starting at 5 minutes on the free plan. Keyword checks look for text in the response body, slow-response alerts compare total time against your threshold, and JSON checks evaluate fields in an API response. Heartbeat monitors work in reverse: your job calls a ping URL, and we alert if no ping arrives in the expected window or if the job calls the /fail path. Maintenance windows suppress alerts. SSL expiry, domain expiry, DNS change and certificate change checks compare the current state with the last known state.

Limitations

• Single vantage point. A result from one location does not prove a site is up or down everywhere. Regional routing, anycast and ISP problems are invisible to us.
• Caching. Some tools cache results, for roughly 30 seconds to 10 minutes depending on the tool, to protect the service and your target. If you just made a change, wait or recheck after the cache expires.
• Third-party data. Google PageSpeed, crt.sh, RDAP servers, DNSBL operators and Team Cymru can be slow, rate-limited or unavailable. When that happens the tool should say the lookup failed, not show a partial answer as complete.
• Rate limits. Heavy use is throttled, and the API is limited to 200 requests per day on the free plan.
• CDN and WAF behaviour. Bot challenges, rate limiting and geo-blocking can return a 403, 429 or challenge page to our servers while real users see the site. Those appear as "up (access restricted)" or a different content signature.
• Not an audit. Results are diagnostic signals. They do not replace a security assessment, a performance test under load or legal advice.

Data sources

How to cite and interpret results

• Quote the time and tool. For example: "Checked with the SiteDownCheck HTTP status tool on October 4, 2026: HTTP 503 from a single location."
• Treat one failure as a prompt to investigate, and repeated failures as evidence.
• Compare with your own tools such as curl, dig and openssl, especially before you raise a ticket with a host.
• Remember that "up" means we received a usable response, not that every feature works.