Uptime probes, redirects, and antibot: why StillOnline shows green when users cannot log in
External uptime tools only see what their HTTP client gets back from the URL you paste. A 302 to a login page, a long redirect chain, or a 200 OK from a bot challenge can look “up” while paying customers are stuck.
StillOnline probes your health URL on a schedule and records the HTTP status code (and timing) on the final response it receives. This guide helps indie SaaS teams avoid false greens without promising features we do not ship (no custom probe headers on Free, no “solve CAPTCHA” mode).
Quick answer
Point StillOnline at a single canonical HTTPS health URL that returns 200 with a small body when the product works—usually GET /api/health on the API host, not the marketing site behind antibot. Fix redirect loops and auth on the health path first; do not rely on the homepage if Cloudflare or Vercel protection returns 200 to bots. Verify with curl -L from outside your network, then register the URL in StillOnline and wait 2–3 probe cycles before trusting green.
What the probe actually does
StillOnline workers issue a scheduled GET (or the method you configure) to the exact URL in the check. On Free, evaluation is primarily status code vs your expected code (typically 200). The probe is not a browser: it does not run JavaScript, solve challenges, or log into your app.
| Probe sees | You might think | Reality for users |
|---|---|---|
200 on / | Site is fine | Marketing page loads; app API is down |
200 after redirects to /login | “Reachable” | Product requires auth; health lied |
301/302 chain | “Eventually OK” | Wrong final URL or timeout on long chains |
403/503 from WAF | Down (good) | Real block—but tune so health is exempt |
Deeper endpoint design: health endpoint design.
Redirects: common mistakes
Redirects are valid for browsers; monitors need a stable final URL.
- HTTP → HTTPS — fine if one hop lands on 200.
- www vs apex — pick one canonical host for the check.
- Regional or locale redirects — can send probes to unexpected paths.
- “Upgrade” redirects during incidents — avoid pointing the check at a status blog URL.
Test like a probe:
curl -sS -o /dev/null -w "%{http_code} final:%{url_effective}\n" -L --max-redirs 5 "https://api.yourproduct.com/health"
Expect 200 and a sensible final: URL. If you need more than a few hops, fix routing instead of raising redirect limits in your head.
Platform notes: Vercel · Cloudflare Workers.
Antibot, WAF, and “challenge” pages
Cloudflare “Under attack” mode, some bot management rules, and generic WAF templates may return 200 with a challenge HTML body to non-browser clients—or block probes with 403.
Practical fixes:
- Dedicated health path on the API subdomain with lighter rules (allow known monitor user-agents only if your provider supports it; document the change).
- Never use the marketing homepage as the only check when it sits behind aggressive bot protection.
- Separate “marketing up” vs “API up” when you upgrade to Pro and add a second check.
StillOnline does not bypass CAPTCHAs or execute JS challenges in v1. If the only public URL is behind interactive protection, fix infrastructure—not the monitor.
StillOnline setup after you fix the URL
- Implement health URL quickstart.
- Start free → add check → GET → expect 200.
- Wait 2–3 intervals (5 min on Free) before calling an incident green.
- Turn on Telegram owner alerts so false greens are caught by humans reading the body once.
For scripted verification, use public status JSON alongside the probe.
Related guides
- Health check URL quickstart
- Health endpoint design: /health vs /ready
- API-only SaaS: what to monitor
- Side project production monitoring checklist
FAQ
Why does StillOnline show operational when my site shows a Cloudflare challenge?
The probe received your configured expected status code (often 200) on the URL you registered—challenge pages can return 200 to non-browser clients. Point the check at an API health path with WAF rules that allow probes, or relax protection on that path only. StillOnline does not render JavaScript or solve CAPTCHAs in v1.
Should I register the URL before or after redirects?
Register the final URL that should return 200 when healthy—usually https://api.example.com/health, not http://example.com if that only 301s. Test with curl -L from outside your network before saving the check.
Can StillOnline follow redirects on health checks?
Probes follow redirects like typical HTTP clients up to normal limits; long or circular chains cause flaky results. Best practice: one canonical HTTPS URL with a direct 200. See health endpoint design.
Does StillOnline let me send custom headers to bypass antibot?
Not as a documented customer feature on Free—configure your edge so /health (or your chosen path) is reachable to external GETs without secrets. Do not put API keys in health URLs.
My check is red but the site works in Chrome—what now?
Browsers run JS and cookies; probes do not. Compare status code and final URL with curl -L. Fix auth on the health route, redirects, or WAF rules—then update the StillOnline check URL in the same change.
Telegram alerts when redirects flip after a deploy?
Yes—once owner alerts are on (Telegram via StillOnline bot), a failed probe pages you even if the marketing site still loads. Update the check URL when you change domains or paths.