はじめに
How checks, incidents and alerts work
Where FastPing checks run from, how often they run, how a failure is confirmed before you are alerted, what each status means and how uptime is calculated.
Every check runs from one FastPing server in Helsinki, Finland (EU). There is no network of probes in other countries, so response times are always measured from Helsinki. They include the network distance from there to your server: a site hosted in Singapore shows higher response times than one in Frankfurt, even when both are fast for their local visitors.
Certificate, domain expiry, email security and blocklist results do not depend on where the check runs. DNS answers can, for names that use geographic routing, and some game hosts filter queries by region.
HTTP checks identify themselves with the User-Agent FastPing-Monitor/1.0 (+https://fastping.app). Checks come from these IP addresses: 89.167.95.28, 2a01:4f9:c012:2db6::1. False alerts, firewalls and allowlisting FastPing explains how to allowlist FastPing.
Each monitor runs at the interval you choose. The shortest interval comes from your plan: every 5 minutes on the free plan and the base paid plan, every minute for $9 a month extra or every 30 seconds for $29 a month extra. Checks every 30 seconds are available for up to 500 monitors. You can always pick a longer interval, up to once a day.
Some types never run more often than a minimum, whatever the plan, because what they measure changes slowly and the data sources should not be hammered:
| Monitor type | Runs at most every |
|---|---|
| UDP port | 1 minute |
| SMTP server | 5 minutes |
| IMAP server | 5 minutes |
| POP3 server | 5 minutes |
| SSL certificate | 1 hour |
| Email security | 6 hours |
| Blacklist | 6 hours |
| Domain expiry | 12 hours |
| Security scan | 1 day |
Check now on a monitor's page queues an immediate check, for example after you fix a problem. It is limited to 30 manual checks per 10 minutes per organisation.
Networks drop the odd packet and servers occasionally stall for a second. To avoid waking you up for that, a single failure never triggers an alert. Here is what happens when a site checked every 5 minutes goes down at 10:00:
| Time | Check result | What FastPing does |
|---|---|---|
| 10:00:00 | Failed: Timed out after 15s | Records the failure, keeps the monitor up and schedules a re-check in 20 seconds. |
| 10:00:20 | Failed again | Marks the monitor down, opens an incident and sends a down alert to every attached channel. |
| 10:05:20 | Succeeded | Closes the incident and sends a recovery alert, which ends with (down for 5m 0s). |
If the re-check succeeds, nothing is sent. The single failed check is still recorded and counts in the uptime figures, so short blips remain visible in the history.
Heartbeat monitors do not re-check: they alert as soon as a ping is overdue by more than the grace period you set.
| Status | Meaning |
|---|---|
| Pending | No result yet: the monitor was just created or resumed, or a heartbeat monitor is waiting for its first ping. |
| Up | The last check passed. |
| Warning | The check passed but something needs attention: a response slower than your threshold, packet loss, a certificate or domain close to expiry, an email security score below your minimum, a security-header grade below 60/100 or fewer players than your minimum. |
| Down | The check failed 2 times in a row (or a heartbeat is overdue). An incident is open. |
| Paused | You paused the monitor, or it was paused because your plan allows fewer monitors. Nothing runs and nothing is sent. |
- Down: once per incident, when the failure is confirmed. It contains the error from the confirming check.
- Recovered: when a down monitor recovers (with the total downtime), or when a warning clears.
- Warning: once when a monitor enters the warning state. It is not repeated while the warning lasts.
- Changed: for monitors that watch for changes, such as DNS records, SPF, DKIM or DMARC records, or a game server's version and map.
Alerts go to the channels attached to the monitor at that moment. Delivery is attempted once per channel: a channel that is unreachable (for example a deleted Discord webhook) misses that alert, so test channels after changing them.
An incident starts when a monitor goes down and ends when it recovers. Its cause is the error message of the check that confirmed the failure. Incidents appear on the monitor's page, in the Incidents panel of the dashboard overview and, for monitors shown on a status page, in the page's incident history.
Uptime is the share of checks that passed. Checks in the warning state count as passed: the service answered, it just needs attention. FastPing keeps daily totals for each monitor and computes the 24-hour, 7-day, 30-day and 90-day figures from them.
Individual check results (time, response time and message) are kept for 7 days. Daily totals and resolved incidents are kept for your plan's history period: 7 days on the free plan and 30 days on paid plans, or 90 days, 1 year or 2 years if you choose a longer history in the plan configurator. Older data is deleted automatically.
Because checks run at intervals, a very short outage that falls between two checks is not seen. Shorter intervals narrow that gap: see Plans, pricing and the plan configurator.
While a scheduled maintenance window covers a monitor, failed checks are still recorded but do not open incidents, and no alerts are sent for it. See Maintenance windows, incident updates and email subscribers.
A paused monitor runs no checks and sends no alerts. A paused heartbeat monitor answers pings with 404 unknown or paused heartbeat. Resuming a monitor runs a check immediately.
If your plan changes to one with fewer monitors, monitors beyond the new allowance are paused automatically, starting with the most recently created, and intervals shorter than the new minimum are raised to it. This happens within an hour of the change.