What Is UptimeRobot and How Do You Set Up Website Monitoring?
Updated
UptimeRobot is a hosted uptime monitoring service that periodically checks whether your website or server is reachable and notifies you when it isn't. You set it up by adding a monitor (a URL or host to watch), choosing a check interval, and attaching alert contacts such as email, SMS, or Slack. It fits anyone who needs external, third-party confirmation that a site is up — from a single personal blog to a team watching dozens of endpoints. The service advertises starting a monitor in about 30 seconds and offers 50 monitors on its free tier.
What UptimeRobot actually monitors
UptimeRobot is not installed on your server; it runs from outside and probes your endpoints on a schedule. The monitor types it supports cover different failure modes:
| Monitor type | What it checks | Typical use |
|---|---|---|
| HTTP(s) | Whether a URL returns a successful response | Websites, APIs, web apps |
| Ping | Whether a host responds to ICMP | Servers and network devices |
| Keyword | Whether specific text appears (or is absent) on a page | Detecting broken pages that still return HTTP 200 |
| SSL | Certificate validity and expiry | Avoiding expired-certificate outages |
| Cron / heartbeat | Whether a scheduled job reports in on time | Backups, cron jobs, background workers |
The distinction that matters most: HTTP monitoring tells you the server answered, while keyword monitoring tells you the right content came back. A page can return a healthy status code while showing a database error, and only a keyword check catches that.
Setting up a basic website monitor
The flow is the same whether you're on a free or paid tier:
- Create an account at uptimerobot.com and log in to the dashboard.
- Add a new monitor. Choose the monitor type (HTTP(s) for a website), then enter the full URL including
https://. - Set the check interval. This is how often UptimeRobot probes the endpoint. Shorter intervals detect outages faster but generate more requests; the fastest intervals are typically reserved for paid plans, so confirm what your plan allows.
- Attach alert contacts. Add at least one destination — email is the default, and SMS, Slack, and other integrations are available. A monitor with no alert contact will log downtime but won't tell anyone.
- Save and verify. After saving, the monitor appears in your dashboard with its current status. Trigger a test by pointing a monitor at a URL you know is down, or temporarily break a keyword match, to confirm the alert actually reaches you.
Expected result: the dashboard shows the monitor as up, and when the endpoint fails, you receive a notification through your chosen channel within the alerting delay.
Alert channels and notification behavior
UptimeRobot sends alerts through email, SMS, Slack, and other integrations. Two settings shape how noisy those alerts are:
- Alert contacts per monitor — you can route different monitors to different people, so the on-call engineer gets the API alert while the marketing site goes to a general channel.
- Alert timing / re-notification — most services let you delay the first alert (to avoid firing on a single blip) and set how often to re-notify while the outage continues. Check the current options in your account, since these vary by plan.
Free plan limits versus paid tiers
UptimeRobot's free tier is generous on monitor count — the service advertises 50 monitors for free — but free plans generally constrain the check interval and the range of alert channels. Paid tiers exist and are listed on the pricing page at uptimerobot.com/pricing/. Before committing, compare three things across tiers:
- Minimum check interval (how fast you can detect an outage)
- Which alert channels are included (SMS and some integrations are often paid)
- Monitor count and log retention (how far back you can review history)
If a 5-minute detection window is acceptable and email alerts are enough, the free tier usually covers a small site. If you need 1-minute checks or SMS, expect to move to a paid plan.
Common setup pitfalls
- False positives from single checks. A brief network hiccup can trigger an alert. Use a confirmation delay or require multiple consecutive failures before alerting.
- Missed alerts because no contact is attached. Creating a monitor without an alert contact is a silent failure — it records downtime but notifies no one.
- Keyword monitors that match the wrong text. If your keyword appears in a site-wide header or footer, the check passes even when the main content is broken. Match text unique to the page you care about.
- Ignoring SSL expiry. SSL monitors catch certificate problems before browsers start warning visitors; add one for every domain you own.
- Alert fatigue. Routing every monitor to every channel trains people to ignore notifications. Segment by severity and audience.
Once your first monitor is live and you've confirmed an alert reaches you, expand by adding SSL and keyword checks for your most important pages, then a cron/heartbeat monitor for any scheduled job whose silent failure would go unnoticed.