Error reference

• Site is reachable and working as intended.

Nothing — you only see UP in the dashboard. We don't email you for UP, only for transitions (recoveries from a previous DOWN are sent as a separate UP-recovery alert).

• Traffic spike or thundering-herd load
• Database queries taking longer than normal
• Overloaded upstream service (e.g. a slow API your site calls)
• Cold-start lag on serverless platforms after low traffic

Check your site's load and recent deployments. Degraded does not pause monitoring — we'll keep checking. If it persists for several checks, investigate performance regressions.

• Server crashed or was restarted
• DNS misconfiguration
• SSL certificate expired
• Hosting provider outage
• Firewall blocking our checks (unlikely — see below)

Check your hosting provider's status page first, then your application logs. Our worker only runs from a single European data center — if you suspect we're being firewalled, see the troubleshooting section at the bottom.

• Domain expired and wasn't renewed
• DNS records were accidentally deleted
• Recent DNS change is still propagating (can take up to 48 hours)
• Typo in the monitor URL

Log into your domain registrar and verify the domain is still active. Check that your A or AAAA records point to a valid IP. If you just made a DNS change, wait 30 minutes and re-check.

• Web server (nginx, Apache, Caddy, etc.) crashed or was stopped
• Container restarted and isn't ready yet
• Firewall configured to block our IP range
• Port 80/443 not open on your hosting platform

SSH or open your hosting dashboard and check whether the web server process is running. Restart it if needed. If you've added a new firewall rule recently, double-check it isn't dropping traffic from European IPs.

• Application crash on the request handler
• Out-of-memory kill on the server
• Misconfigured load balancer health checks
• TCP keepalive timeout in front of the server

Check your application error logs for crashes around the alert time. If you're behind a load balancer or proxy (Cloudflare, AWS ALB, etc.), check its status page and your origin health.

• Database query hanging or taking forever
• Application stuck in an infinite loop
• Massive traffic spike overwhelming the server
• Network bottleneck between our worker and your hosting region

Check your application's request handlers — particularly any that hit the database or external APIs. Look for slow queries or deadlocks. If your site is hosted far from Europe, some latency is expected, but a full 8-second timeout means something is genuinely stuck.

• Auto-renewal failed silently (Let's Encrypt requires reachable port 80)
• Manually-managed certificate wasn't renewed in time
• DNS validation broke (CNAME or TXT record was changed)

If you use Let's Encrypt or a managed certificate (Cloudflare, AWS ACM, Vercel, etc.), check that auto-renewal still works — usually a quick force-renew fixes it. We send 30, 14, and 7-day warnings before expiry as separate alerts so you have time to act.

• Self-signed certificate left on a production site
• Intermediate certificate not bundled with the leaf cert
• Certificate from a deprecated or revoked authority

Most production hosts and CDNs handle this automatically — if you're seeing it, you've likely uploaded a custom certificate. Make sure the full chain (leaf + intermediates) is configured. Tools like SSL Labs (ssllabs.com/ssltest) will pinpoint which intermediate is missing.

• Wildcard certificate that doesn't cover the subdomain (e.g. *.example.com vs deeper.sub.example.com)
• Server returning the wrong virtual-host's certificate
• Recent domain rename without re-issuing the cert

Check which hostnames are listed on your certificate (Subject Alternative Names). If your monitor URL isn't covered, re-issue the cert with the right hostname or set up a redirect to the covered domain.

• Cloudflare or another CDN's WAF blocking our user-agent
• Server expecting authentication on a page we shouldn't need to log in for
• Misconfigured rewrite rules returning 404 for the homepage
• Rate limiter triggered (HTTP 429)

Check our user-agent (`web-down/1.0 (+https://web-down.com)`) is allowed by your WAF or rate-limiter rules. If you're seeing 404 specifically, double-check the monitor URL is the one you actually want to test.

• Page or route was deleted or renamed
• A recent deployment introduced a routing typo
• Reverse proxy is misrouting the request
• Monitor URL has a trailing slash where the site expects none, or vice versa

Check the URL in your browser. If it loads, the issue is specific to our request — check your reverse proxy or WAF logs. If it doesn't load there either, restore the missing route or update your monitor to point at the right URL.

• Cloudflare rate-limiting rule applied to all IPs
• Application-level rate limiter not whitelisting the monitor
• DDoS protection in 'I'm under attack' mode

Whitelist our user-agent or IP in your rate-limiter. Our checks are 5 minutes apart from one European data center — they should never trip a real rate-limit.

• Application crash (uncaught exception, panic, etc.)
• Database connection failed
• Out of memory or disk space
• Upstream service (API your site depends on) failed

Pull up your application's error logs for the alert timestamp. 5xx errors almost always have a stack trace showing exactly what crashed.

• Uncaught exception in your application code
• Failed database query that wasn't handled
• Misconfigured environment variable causing startup failure

Check application logs. The exact stack trace will pinpoint the cause. After fixing, redeploy and the next monitor check (within 5 minutes) will confirm recovery.

• Application server (Node, Python, Ruby, etc.) is down
• Application is restarting after a deployment
• Misconfigured upstream in nginx/Apache

Restart the application server. If you just deployed, check the deployment logs — the new version may have failed to start. Many platforms (Vercel, Fly.io, Render) auto-rollback failed deploys; verify yours did.

• Maintenance mode enabled
• Auto-scaling temporarily failing to keep up with load
• Health-check failure causing all instances to be marked unhealthy

If this is a planned maintenance, you can pause the monitor in the dashboard so you don't get spammed with alerts. Otherwise, investigate load and scaling.

• Slow database query blocking a request handler
• Deadlock in application code
• Network problem between proxy and app server

Check application performance and database query times. Often resolves itself if it's a transient slow query, but recurrent 504s point at a real performance regression.

• Traffic surge (good kind: viral post, marketing campaign)
• Slow database query that grew with data volume
• External service your site calls is lagging

Check your performance monitoring (database, APM, logs). If the spike is from real traffic, you may need to scale up. If it's a slow query, profile it and add an index.

• Auto-renewal scheduled but hasn't run yet
• Manually-managed certificate that needs renewing

If you use Let's Encrypt, Cloudflare, or a managed certificate, this should renew automatically — verify auto-renewal still works. If you manage the cert yourself, renew it before the 7-day mark to avoid downtime.

• Intentional hosting migration
• DNS hijack (rare but serious)
• Multi-IP DNS round-robin returning a different IP

If you made the change yourself, you can ignore this. If you didn't, log into your DNS provider immediately and verify your records — and check that your registrar account hasn't been compromised.

• Intentional redirect added (e.g. moving from HTTP to HTTPS, or to a new domain)
• Page was archived and now returns a different code
• Server-side change in framework or routing

Verify whether the new status code is intentional. If yes, no action needed. If no, investigate the deployment that introduced the change.

• Intentional redirect addition (CDN, www-to-apex)
• Compromised hosting redirecting through an attacker site (extremely rare)
• Misconfigured CDN or proxy adding a hop

Check the new redirect chain shown in the alert. Each redirect adds latency for real visitors, so even an intentional change is worth understanding.

• Migrated to a new hosting provider
• Added or removed a CDN in front of the site
• Upgraded the web server software

If you made the change, no action needed. If you didn't, this could indicate someone changed your hosting setup without telling you — worth a quick check.