False alerts, firewalls and allowlisting FastPing

Every down alert is based on 2 failed checks in a row, 20 seconds apart, so a down alert means FastPing really could not reach the service twice. Before changing anything, open the monitor and read:

• Recent checks: the exact message of each check, for example HTTP 403, socket hang up or Timed out after 15s;
• Incidents: when it started, how long it lasted and its cause.

Then repeat the check with the matching free tool, such as the Website checker or the Port checker. The tools run on the same server as the monitors, so they see what the monitor sees. Check error messages explained explains each message.

All checks come from one server in Helsinki, Finland. Its addresses are 89.167.95.28 and 2a01:4f9:c012:2db6::1. Allow them for the protocols your monitors use.

• HTTP checks (website, keyword, API) send the User-Agent FastPing-Monitor/1.0 (+https://fastping.app). Rules that block unknown clients or "bots" often block it.
• Ping needs ICMP echo requests and replies to be allowed. Without them, FastPing falls back to measuring TCP connections on ports 443 and 80.
• Game server queries use UDP (Minecraft Bedrock and Steam A2S) or TCP (Minecraft Java and FiveM/RedM) on the query port.
• Port monitors need the monitored TCP port to accept connections from our address.

Web application firewalls, CDNs and DDoS protection services often challenge or block automated clients. Typical symptoms: HTTP 403, HTTP 429, HTTP 503 with a challenge page, or socket hang up, while the site works fine in your browser. Add an allow or skip rule for FastPing in the service's firewall settings, matching our IP address, our User-Agent or both, and exclude it from rate limiting. If the service offers "bot fight" or "under attack" modes, they usually apply before custom rules; check its documentation for how to exempt monitoring.

If you restrict traffic by country, remember that checks come from Finland (EU). A site that only admits visitors from one country will look down to FastPing unless our address is allowed.

When a hostname has both IPv4 and IPv6 addresses, FastPing connects over IPv4. If your A record points to an old server while the AAAA record is correct, visitors on IPv6 are fine but FastPing (and everyone on IPv4) is not: fix the A record.

A response that takes longer than the monitor's timeout (15 seconds by default) counts as a failure. If an endpoint is slow by nature, such as a report generator, raise the timeout (up to 60 seconds) and set Warn if slower than to be told about slowness without a down alert. Remember that response times include the distance from Helsinki to your server: see How checks, incidents and alerts work.

Browsers repair some certificate problems on their own, most often a missing intermediate certificate, which they download or have cached. FastPing validates the certificate the way API clients and command-line tools do, without those repairs. unable to verify the first certificate almost always means the server must send its full certificate chain. Check it with the SSL checker.

A service that fails intermittently produces a series of short incidents. FastPing reports each one rather than hiding them, because intermittent failures are what your users notice. Look at the times of the incidents: a regular pattern (every hour, every night) usually points to a scheduled job, a backup, log rotation or a restart. For planned work, schedule a maintenance window so that no alerts are sent.

Contact support with the monitor's name, the time of the alert in UTC and the message shown in Recent checks. We can look at what our server saw.