Site Monitoring for Uptime, Content, SSL, and Response Time
A site can be up and still be broken, serving an error page or a stale cache. UptimeHub checks that yours is not just reachable but actually right, from six regions, and shows the world it is healthy.
Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
In short
Site monitoring is the ongoing check that a website is online, serving the correct content, and responding quickly, run from outside your own hosting. UptimeHub checks your site from six global regions and can verify that an expected keyword appears on the page, so a silent error screen or wrong deploy is caught even when the server returns a 200. It watches SSL certificate expiry and tracks response time so you see slowdowns before they become outages, auto-retries from a second region before alerting, and reaches you in seconds over Slack, email, SMS, or webhook. A branded public status page shows your users the current state without them ever emailing support.
Why teams pick us
Uptime monitoring built for how you actually work
Anyone running a website who wants uptime, content, SSL, and speed watched with a status page for users.
More than a green dot
Confirm an expected keyword is on the page so a broken deploy or error screen is caught even when the HTTP status still reads OK.
SSL and response time
Get warned before a certificate expires and watch response time from six regions so a creeping slowdown is visible before it turns into downtime.
Branded status page included
Publish a status page on your own domain with your brand, so users can check the current state themselves instead of opening a ticket.
What a basic ping misses on a live website
Most website outages that cost money are not a dead server. The host answers, the load balancer returns a status code, and the page is still useless to a customer. That is why a site monitoring plan needs more than one kind of check, and why the cheapest tools that only test reachability tend to page you late or not at all.
The table maps the failures that actually take revenue sites down to the check that catches each one, and which UptimeHub plan carries that check.
| Failure | What a reachability check sees | Check that catches it | Plan |
|---|---|---|---|
| Broken deploy shows an error template | 200 OK, all green | Keyword check on text only the real page contains | Pro and Business |
| Origin down behind a CDN | Cached page, all green | HTTP check on an uncached path | Every plan |
| Certificate expired over a weekend | Connection refused or browser warning | SSL expiry warning days ahead | Every plan |
| DNS record changed or hijacked | Wrong server answers, maybe green | DNS record check | Pro and Business |
| Slow page under load | Up, just late | Response time from six regions | Every plan |
| Outage in one region only | Green from the checker's region | Multi-region checks with retry | Every plan |
Plan contents are read from the UptimeHub pricing page. Keyword and DNS checks start on Pro.
If your site takes payments, the keyword check is the one to set up first. It is the only check on this list that notices a page that loads perfectly and says the wrong thing. The cost of website downtime is mostly made of these quiet failures, because nobody is paged while they run.
What site monitoring costs per monitor
On annual billing UptimeHub Starter is $24 a month for 20 monitors, which works out to $1.20 per monitor. Pro is $49 a month for 100 monitors checked every 30 seconds, about 49 cents each, and Business is $99 a month for 400 monitors, roughly 25 cents each. Month to month the same plans are $49, $99 and $199. Every plan includes a branded status page, so there is no second tool to pay for.
Per-monitor cost is the honest way to compare, because vendors bundle very different monitor counts, intervals and seat rules into plans with similar names. Before you choose, read how the main alternatives charge: our UptimeRobot pricing breakdown, the Pingdom pricing guide (Pingdom bills by the number of uptime checks, from $18 a month for 10) and the StatusCake plan comparison. The uptime monitoring pricing comparison puts all of them in one table, and if the status page is the part you care about most, status page pricing compares the dedicated status page vendors.
A small marketing site rarely needs more than Starter. A store, a SaaS app or an agency with client sites usually lands on Pro, because the keyword check and the 30 second interval are what shorten an outage from minutes to seconds.
Site monitoring settings for a marketing page and a revenue path
Point the first check at a dedicated health endpoint that also confirms the database and key dependencies answer, not just the homepage. A green check then means the app can serve a customer, not merely that the web server replied. Add login, checkout and search as separate monitors, because they break independently of the homepage.
The settings below are the ones we would start from. The interval sets the ceiling on how long an outage runs before anyone hears about it, and the confirmation rule is what keeps a one-off network blip in one region from waking someone up.
| Setting | Marketing page | Revenue path (checkout, login, paid API) |
|---|---|---|
| Interval | 1 to 5 minutes | 30 seconds to 1 minute |
| Regions | 2 to 3 | 3 or more |
| Confirmation before alerting | 2 failures | 2 to 3 failures, from more than one region |
| Alert channel | Email or Slack | Slack plus SMS |
| Extra checks | SSL expiry | Keyword, SSL expiry, DNS, API endpoint |
Starting points, not limits. UptimeHub checks every minute on Starter and every 30 seconds on Pro and above.
Review what fired after the first week. False alarms mean the confirmation rule is too loose or a region is flaky; an incident that slipped through means a check is missing for the thing that broke. Turn on recovery notices too, so a closed incident tells the team it is closed. If your site depends on an API or scheduled jobs, add API monitoring and cron heartbeat checks next, since neither shows up in a page check.
More use cases
Related features
FAQ
Questions teams ask about Websites
Add your URL to a monitoring service and let it check the page on a set interval from outside your network. UptimeHub loads the page every 30 to 60 seconds from six global regions, confirms it returns a healthy response, and alerts you in seconds over Slack, email, SMS, or webhook when it does not.
For a site that affects revenue, check every 30 to 60 seconds so you catch an outage before customers do. Slower intervals like five minutes are fine for low-stakes pages but let downtime run longer before you hear about it. UptimeHub checks every minute on Starter and every 30 seconds on Pro and above.
Yes. A keyword check confirms a specific word or phrase is present in the page, so you catch a page that loads with a 200 status but shows an error, a blank template, or a defacement. UptimeHub treats a missing keyword as a failure and alerts you just like it would for downtime.
Alerts reach you over Slack, email, SMS, or webhook within seconds of a confirmed failure. UptimeHub auto-retries from a second region first, so you are only paged for a real outage, and your branded status page updates automatically so visitors see the incident without emailing you.
Start monitoring in two minutes
Add your first monitor, pick your regions, and get alerts in seconds by Slack, email, SMS, or webhook. Read-only external checks that never touch your servers, plus a branded status page included.