Uptime Monitoring for SEO
Free website uptime monitoring, built for SEO. RankNibbler checks your site's real server response on a schedule, tracks its uptime and response time, and tells you when it goes down. Because when your site is down, Googlebot can't crawl it — and repeated downtime quietly costs you rankings.
Why uptime matters for SEO
Downtime isn't only a user-experience problem — it's a crawl and indexing problem. When Googlebot repeatedly hits 5xx errors or timeouts, it backs off and slows its crawl rate to avoid hammering a struggling server, so your new and updated pages are discovered and re-indexed more slowly.
If the errors persist, the cost goes up. Prolonged downtime — on the order of a couple of days of server errors — can cause Google to drop the affected pages from its index until they recover. The damage depends entirely on how you go down:
- A 503 Service Unavailable with a Retry-After header is the correct, low-risk way to signal short, planned maintenance — Google understands it and comes back.
- An unhandled 500, a connection timeout, or a DNS failure is the damaging kind: it looks like a broken site, not a paused one.
The point of monitoring is to catch an outage early — before a crawl happens to coincide with it — and to know whether a real problem or a one-off blip caused it.
How RankNibbler's uptime monitoring works
Add a URL and choose how often to check it: every 5, 15, 30 or 60 minutes. Each check is a direct HTTP request that measures the real server response time — there's no proxy in the path, so the timing you see is your server's, not ours.
The up/down rules are deliberately transparent, so you always know what an incident means:
- Up — the site returns an HTTP 2xx or 3xx.
- Down — a 4xx or 5xx response, a 10-second timeout, or a connection, DNS or SSL/TLS error.
Accurate alerts you can trust
RankNibbler is built to be accurate, so when it tells you something's wrong, it's worth acting on:
- Confirmed before it counts. A check that fails is re-run a couple of times to confirm a genuine outage before it's recorded — so a momentary blip is filtered out, not flagged.
- Bot-protection smart. When a check meets Cloudflare-style protection (a 403, 429 or 503), RankNibbler re-verifies through a real browser and correctly reads a guarded-but-healthy site as up.
How to set up uptime monitoring
You can have a monitor running in under a minute.
1. Open Uptime Monitoring and add a monitor
In your dashboard, open Uptime monitoring and click Add monitor. Enter the URL you want to watch, choose how often to check it — every 5, 15, 30 or 60 minutes — and tick Email me if it goes down if you'd like alerts.
2. Watch your sites from the dashboard
Every monitor shows its live status, 24-hour uptime, last response time and check interval, and the page refreshes on its own — so it works as a status board for all your sites at once.
3. Open a monitor for the full history
Click View on any monitor for the detail: current status, average response time, an uptime history strip and a response-time chart across the last 24 hours, 7 days, 30 days or all time — plus a log of every check with its status code and timing.
Downtime alerts
When you create a monitor you can opt in to an email alert when it goes down — and again when it comes back up, so you're not glued to the dashboard to know your site's healthy.
Maintenance windows
Planned work shouldn't wake anyone up or dent your uptime figures. Open Uptime monitoring, click Maintenance, then Schedule maintenance. Give the window a name, set when it starts and ends, and choose the monitors it covers, or all of them.
- One-off or repeating. A window can happen once, or repeat every day, week or month (every 2 weeks, for example), until a date you pick or indefinitely.
- Change or skip a single occurrence. Move one date, or skip it, without touching the rest of the schedule.
- Alerts are paused, checks aren't. During a window, monitors keep checking your site, but no down or back-up emails and no uptime webhooks go out. If a site is still down when the window ends, you're alerted then.
- Fair uptime figures. Time inside a window is shown as maintenance, not downtime, so it doesn't lower your uptime percentage. Outages that happened entirely during maintenance are labelled as such.
A monitor that's in a window shows a banner on its page, along with its next scheduled maintenance.
Monitoring API
More than web pages
A monitor usually watches a web page, but plenty of things that break aren't pages. You can also check:
- A port, over TCP or UDP: is the database, the cache or the game server still accepting connections? You can send a line of text and insist on a particular reply.
- Ping: the simplest question there is, and the right one for a router or a firewall.
- A DNS record: catch the outage that happens before anyone reaches your server, such as a record edited by mistake.
- A mail server, over SMTP, POP3 or IMAP, including signing in to prove a mailbox still works.
- Your own status page: we read a field out of the JSON or XML your service returns and alert when it stops saying what it should, even though the page still loads.
Example: a mail server. Pick the mail check, enter mail.example.com, choose STARTTLS and port 587, and add the mailbox username and password. We connect every few minutes, read the greeting and sign in. If the certificate expires, the service stops or the password is changed, you hear about it before your customers do.
Example: DNS. Pick the DNS check, enter example.com, choose the MX record type and type your mail provider's host as the expected answer. If those records are ever changed or removed, the monitor goes down, even though your website is still up.
Checks that aren't web pages take a host on its own, such as mail.example.com, rather than a full address. Everything else is the same: the same intervals, the same alerts, the same uptime reports. One note on ping: it needs a low-level network permission that some servers don't allow, and we say so plainly rather than pretending the host is down.
Why it went down
When a check fails, we don't stop at "it's down". We run the same address again in stages, one after another: look the name up, connect to the port, check the certificate, then make the request. The first stage that fails is the likely cause, and we show it on the outage in plain words, such as "the certificate expired 2 days ago" or "the port refused the connection". Where a connection failed, we add a traceroute showing how far the request got.
Sometimes everything answers when we look again, which usually means a blip that has already passed. We say that too, rather than inventing a cause.
Who gets alerted
By default an outage emails the people you pick from your workspace. You can also add alert contacts: people who should hear about outages but don't have a RankNibbler login, such as a client, an agency or an out-of-hours address. A contact can have several email addresses.
Teams group people together. Put your workspace members and contacts in a team called Support, point a monitor at the team, and everyone in it is alerted. If somebody is in a team, a contact and the monitor's own list, they still get one email: we merge everyone by address first.
Each address has a severity:
- All alerts: every monitor that address covers.
- High importance only: only monitors you have marked as high importance. Handy for an out-of-hours address that shouldn't be woken by a staging site.
Every alert to a contact has an unsubscribe link. If they use it, we stop emailing that address and show it as opted out. We can't switch it back on for them: they have to ask you to add them again, which keeps us on the right side of their inbox.
You can also look back at what was sent: every alert, who it went to, and whether it was delivered, failed or skipped. The history covers the last 120 days.
Everything above is also available through the Monitoring API: create and manage monitors, read raw check results, pull uptime, outage and performance reports, manage alert contacts and teams, and schedule maintenance windows from your own tools or deploy scripts.
Frequently asked questions
Does website downtime affect SEO?
Yes. Short blips are usually harmless, but repeated 5xx errors make Googlebot slow its crawl rate, and prolonged downtime (around two days of server errors) can drop affected pages from Google's index until the site recovers.
How often does RankNibbler check my site?
On a schedule you choose: every 5, 15, 30 or 60 minutes.
What counts as "down"?
A 4xx or 5xx response, a 10-second timeout, or a connection, DNS or SSL/TLS error. An HTTP 2xx or 3xx counts as up.
Why do other monitors report my site as down when it's actually up?
Bot protection such as Cloudflare returns a 403, 429 or 503 to automated checks. RankNibbler re-confirms those through a real browser, so a healthy but bot-guarded site isn't falsely flagged down.
What is a good uptime percentage?
99.9% ("three nines") is the common baseline — about nine hours of downtime a year. Ecommerce and SaaS sites usually aim higher.
Does it measure response time?
Yes. Every check records your server's real response time, with last and average values and a response-time chart.
Will I be alerted if my site goes down?
Optionally, yes — you can have an email sent when a monitor goes down and again when it recovers.
Can I pause alerts during planned maintenance?
Yes. Schedule a maintenance window, once or repeating daily, weekly or monthly, for some or all of your monitors. Checks keep running, but no alerts or webhooks go out, and the time isn't counted as downtime in your uptime figures.
Is there an API for uptime monitoring?
Yes. The Monitoring API lets you create and manage monitors, read every check result, pull uptime and outage reports, and schedule maintenance windows with an API key.
Is RankNibbler's uptime monitoring free?
Yes. It's free and part of the wider RankNibbler SEO toolset.
Start monitoring your site
Add your first monitor in under a minute — it's free, and it sits alongside the rest of your SEO tools.