Why Your Monitor Status Looks Wrong, and How to Fix It

Most "wrong" statuses make sense once you know the rule the monitor applies. Each monitor type has its own:

• HTTP(S) and API: the monitor requests the URL with the method you chose (GET by default), follows redirects and compares the final status code with the expected status, which is 200 unless you change it. No answer within the timeout (30 seconds by default, adjustable from 5 to 60) is a failure.
• Keyword: the page must return a 2xx or 3xx status, then your text must be in the raw HTML (or absent from it, in absent mode). The match is case-sensitive and no JavaScript is run.
• TCP ping and port: the monitor must be able to open a TCP connection to the host and port within the timeout (10 seconds by default).
• SSL certificate: fails when the certificate expires within your threshold (7 days by default) or browsers would not trust it.
• DNS record: fails when no record of the chosen type holds the value you expect, or the record disappears.
• Domain expiry: fails when the registration expires within your threshold (7 days by default).
• Heartbeat: fails when no ping has arrived within the grace period.

Website, keyword, API, ping and port monitors are checked from London, New York and Sydney, and only change to down when at least two of the three locations fail. SSL, DNS, domain expiry and heartbeat monitors run on our main server and are re-tested three seconds after a failure.

A firewall or bot filter is blocking the checks. Web application firewalls, CDN bot protection and security plugins often answer automated requests with 403, 429 or a challenge page. Our probes do not send a browser identity, so they can be caught by rules that let you through. PulseStack™ does not publish a list of probe IP addresses; on paid plans, add a custom request header with a long random value to the monitor and allow that header in your firewall. Monitoring locations has examples for Cloudflare, AWS WAF, Nginx and Apache.

The expected status does not match. If the page legitimately returns something other than 200, for example 204 from an API or 401 from a protected endpoint, set that code as the expected status under Advanced settings.

The URL redirects somewhere unexpected. Redirects are followed, so a URL that now redirects to a login page, a moved page or a 404 is checked at its final destination. Load the exact URL in a private browser window to see where it ends up, and monitor the final address.

The page is slow. A response that takes longer than the timeout counts as down. Check the response time chart: if it has been climbing, the slowness is real and worth fixing. If the page is always slow by design, raise the timeout (up to 60 seconds).

The server rejects HEAD requests. Some servers answer HEAD with 405. Switch the method back to GET under Advanced settings.

Visitors from some countries are blocked. Geo-blocking that rejects the United States or Australia makes New York and Sydney fail, which is two out of three, so the monitor goes down. Allow those regions for monitoring requests, or monitor with a custom header your firewall lets through.

DNS has recently changed. While a change propagates, our probes can still reach the old server. The DNS propagation checker shows which public resolvers have picked up the new record.

A heartbeat monitor stays up as long as the time since the last ping is within the grace period. The grace period runs from 1 to 60 minutes, so set it a little longer than the gap between runs: about 20 minutes for a job that runs every 15 minutes, or the full 60 minutes for an hourly job that sometimes runs late. A heartbeat suits jobs that run at least once an hour.

• Check the URL. Copy the heartbeat URL from the monitor again; a mistyped token sends pings nowhere. Both GET and POST requests are accepted.
• Ping when the job finishes. Put the request at the end of the job, so a run that crashes halfway does not report success. In a shell script, && curl -fsS https://pulsestack.co.uk/api/heartbeat/YOUR-TOKEN after the main command only pings when it succeeds.
• Make sure the server can reach us. Outbound firewalls on the machine running the job can block the request.

More detail is in the guide to heartbeat monitoring.