If PulseAPI reports your monitor as down but you can access the site normally in your browser, there are several common explanations. This article walks through the most likely causes.
PulseAPI checks your endpoint from its monitoring infrastructure, which may be in a different geographic region than you. A routing issue, DNS propagation delay, or CDN edge problem could affect one network path but not another.
Check: View the check history for your monitor (Monitors → [Your Monitor] → Check History). Look at the error message in the failing checks. If you see "connection refused" or "DNS resolution failed," there may be a network-level issue between PulseAPI and your server.
If your server has a firewall, WAF (Web Application Firewall), or rate limiter, it may be blocking requests from PulseAPI's monitoring IPs — causing check failures that look like downtime.
Check: Look at your server's access logs for requests from PulseAPI's monitoring infrastructure. If you see 403 responses or blocked requests, allowlist PulseAPI's IP ranges in your firewall or WAF. Contact support for PulseAPI's current IP ranges.
Your server might be responding slowly enough that PulseAPI's request times out, even though the page eventually loads in your browser (which has a longer tolerance for slow responses).
Check: Look at recent check response times in the check history. If checks show high response times (close to your configured timeout) before failing, the server is likely responding slowly or intermittently.
Fix: Increase the monitor's Timeout setting if you expect slow responses, or investigate why response times are elevated.
Your server may be returning a different status code than PulseAPI expects. For example, your endpoint might return a redirect (301, 302) that PulseAPI's rule treats as a failure.
Check: In the check history, look at the Status Code column for the failing checks.
Fix: Update your alert rule's expected status code, or update your endpoint to return the expected code directly.
If SSL Verification is enabled and your SSL certificate has expired, has an invalid chain, or uses a self-signed certificate, PulseAPI will fail the check even if the site appears to load in your browser (which may show a warning but proceed).
Check: Look for SSL-related error messages in the check history.
Fix: Renew your certificate, or if using a self-signed cert for internal monitoring, disable SSL Verification on the monitor.
If the failure was brief (one or two checks) and the monitor recovered on its own, it may be a false positive — a transient network hiccup or brief server spike that self-corrected. PulseAPI records what it observes; if the check failed, the check really did fail at that moment.
For strategies to reduce false positives, see Understanding and Reducing False Positives.
Still have questions? Contact support.