Redirect checks

DomainCare follows the redirect chain from every entry point of your domain and verifies that all paths converge on a single canonical URL. Redirect loops, broken chains, and unintended destination changes all fire alerts.

What it monitors

• Entry point probes — for apex domains, DomainCare probes all four variants: http://, https://, http://www., and https://www.; for subdomains, it probes http:// and https://
• Canonical URL — whether all probes resolve to the same final origin (e.g. all land on https://example.com)
• Redirect loops — whether any probe encounters the same URL twice in the chain
• Chain length — chains longer than 6 hops are treated as a failure
• Final reachability — whether every probe ends at a reachable URL (non-null final destination)
• Status codes — unexpected 3xx codes in the chain (e.g. a 302 where a 301 is expected) are flagged

How often it runs

The redirect check runs every 12 hours (43,200 seconds) by default. Pro and Business plans can override this per domain via per-check controls. All entry point probes run in parallel, so the total check time is bounded by the slowest single probe rather than the sum of all probes. Each hop in a chain has an 8-second timeout.

Alerts this check produces

Event	Tone	When it fires
redirect_chain_problems	Failure	A redirect loop is detected (same URL seen twice in the chain)
redirect_configuration_issues	Failure	All probes fail to reach a final URL, or the chain exceeds 6 hops
redirect_url_changed	Warning	The resolved canonical URL changed from its previous recorded value
redirect_status_code_issues	Warning	A probe returns an unexpected status code during the chain

What to do when alerts fire

• redirect_chain_problems — loop detected. Open your web server or CDN redirect rules and trace the chain manually. Loops most commonly occur when both http:// → https:// and https:// → http:// redirects exist simultaneously, or when a CMS permalink setting conflicts with a server-level redirect rule.

• redirect_configuration_issues — chain too long. A chain of more than 6 hops adds latency and is penalized by search engines. Flatten the chain: instead of A → B → C → D, configure A → D directly in your server rules.

• redirect_configuration_issues — all probes fail. Your domain is not responding to any of the entry point probes. Check whether the domain resolves in DNS and whether your web server is running. This alert often co-occurs with a website_down uptime alert.

• redirect_url_changed. The canonical destination changed from its last recorded value. Verify this was intentional — for example, a domain migration or a CMS URL structure change. If it was not intentional, check your CDN configuration, load balancer rules, or .htaccess / nginx.conf for unexpected changes.

• redirect_status_code_issues. A 302 (temporary) redirect where a 301 (permanent) is expected prevents search engines from passing link equity and may cause repeated redirect resolution on every request. Update the redirect rule to return 301 for permanent destinations.

Related

• Uptime checks
• SSL checks