StatusEagle
Uptime monitoring

Free uptime monitoring you can trust at 3 AM

Check websites, APIs, servers and ports every 60 seconds from 3 locations. StatusEagle retries and cross-checks each failure, so an alert means your service is down, not that a network hop blinked.

Uptime · 30-Day Reliability
Live check snapshot
Active
Current Availability99.99%
Allowed Downtime4m 23s / month
Cross-check Retry2 locations verified
Active Monitors10 / 10 (Free Plan)

3 AM alert verification · Zero false alerts

1

What you can monitor

MonitorAnswers
Does the URL return the expected status, how fast?Sites, landing pages, REST APIs
Is the host reachable, what’s the latency and packet loss?Servers, VMs, gateways
Is the service accepting connections?Databases, SMTP, SSH, game servers
Is expected text present (or an error absent)?Checkout, login, “200 but broken” pages
Did the scheduled job report in on time?Backups, imports, report generation
Is the device up; what are CPU and memory?Routers, switches, firewalls (SNMP v1/v2c/v3)
2

What uptime percentages really allow

“Three nines” sounds close to perfect. In minutes, the difference between targets is large:

Based on an average month of 30.44 days and a year of 365.25 days.

Your monitoring interval should be small relative to your budget. If you promise 99.95% (about 22 minutes a month), 5-minute checks can consume a quarter of that budget before the first alert.

AvailabilityDowntime / monthDowntime / year
7 h 18 m3 d 15 h 40 mInternal tools, side projects
3 h 39 m1 d 19 h 50 mMarketing sites
43 m 50 s8 h 46 mMost SaaS SLAs
21 m 55 s4 h 23 mPayments, checkout, core APIs
4 m 23 s52 m 36 sInfrastructure providers
3

The alert you can trust

An uptime tool is only as useful as the team’s willingness to act on it. If one alert in five turns out to be noise, people start waiting a minute to “see if it clears”. StatusEagle’s rule is simple: a failure must survive a retry and be confirmed from more than one location before it becomes an alert.

4

Uptime calculator

Type an availability target to see how much downtime it allows. Useful when you’re writing an SLA or deciding what’s realistic. There’s also a full-page uptime and SLA calculator with per-day and per-week figures.

99.9% allows 43 m 50 s of downtime per month.

5

How long until you know? A worked example

Detection time is the part of an outage nobody sees on a graph. With interval-based monitoring, it has three parts:

So on a 5-minute interval, the worst case before an alert is just over five minutes, and the average is around two and a half. On a 60-second interval, the worst case is just over a minute. If your SLA budget is 22 minutes a month (99.95%), that difference matters.

Waiting for the next check. If the site fails one second after a check, up to one full interval passes before the next. On average that’s half an interval.
Verification. The retries from the same location and the confirming check from another location. This adds seconds, not minutes.
Delivery. An email may take a minute to arrive and be noticed; an SMS or phone call reaches someone faster.
6

Monitoring servers that aren’t on the public internet

Ping, port and HTTP checks run from StatusEagle’s monitoring locations, so the target has to be reachable from the internet. For a firewalled server, allow inbound checks from StatusEagle’s monitoring IP addresses publish the IP list and link it here , and only on the port you’re monitoring. For jobs and services that can’t accept inbound traffic at all, flip the direction: have them send a heartbeat out to StatusEagle, which alerts you when one doesn’t arrive.

# crontab: back up at 02:00, then report success 0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 "$HEARTBEAT_URL" > /dev/null The && means the heartbeat is only sent if the backup exits successfully. Copy $HEARTBEAT_URL from the cron monitor in your dashboard.

Configuration / Request snippet
# crontab: back up at 02:00, then report success
0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 "$HEARTBEAT_URL" > /dev/null
7

Measuring uptime for an SLA

Define “down”. Unreachable? Any 5xx? Response above a threshold? Write it down.
Decide on maintenance. Most SLAs exclude announced maintenance. Use maintenance windows so the data matches the contract.
Measure from outside. Internal health checks miss DNS, CDN and certificate failures that customers hit.
Publish it. A status page with uptime history turns your SLA into something customers can check.
8

Five common uptime monitoring mistakes

60-second checks from 3 locations on every paid plan, from $10/month.

10 monitors · no credit card

Only monitoring the homepage. It’s often cached at the CDN and stays up when the app behind it is down.
Expecting only HTTP 200. Health endpoints that redirect or require auth need their real expected code.
Ignoring certificates and domains. Both cause total outages and both are predictable weeks ahead.
One alert channel. Email alone is easy to miss at night; add SMS or a phone call for critical monitors.
No monitoring of the monitor’s blind spots. Background jobs don’t answer HTTP, use heartbeats.
Uptime monitoring
Status page software
Website vs uptime monitoring
Compare monitoring tools
COMPLEMENTARY CHECKS

Related monitoring

Pair these monitoring checks to ensure complete stack coverage.

FAQ

Frequently asked questions

Still deciding? Start monitoring free and verify your first service in ~2 minutes.

Uptime monitoring is the continuous checking of whether a website, API, server or port is reachable and responding, combined with a record of the percentage of time it was available.

GET STARTED IN MINUTES

Your first monitor takes about two minutes.

Free plan: 10 monitors, 3 locations, 1 status page. No credit card.