How to Set Up Website Uptime Monitoring with UptimeRobot

Last verified: September 10, 2026
By: PerfMonitoring

For a normal public website, UptimeRobot's HTTP(s) monitor is the most direct starting point. It makes web requests to your URL and evaluates the response against the monitor's success rules. The current UptimeRobot dashboard flow is Add New Monitor > HTTP(s), followed by the URL, alert contacts, interval/region choices, advanced settings when needed, and Create monitor. [1]

The valuable part is not creating the monitor—it is configuring it so that “DOWN” means something useful. Timeout, request method, accepted status codes, redirects, monitoring location, and UptimeRobot's retry behavior can all affect whether an incident reflects a real user-facing outage or a monitoring mismatch. [2][3]

What You'll Accomplish

You will:

1. create an HTTP(S) monitor for a real website or health endpoint;
2. define what HTTP responses should count as healthy;
3. configure notification contacts without immediately paging everyone;
4. understand the difference between monitoring interval and request timeout;
5. verify several successful checks before trusting the monitor;
6. understand the current retry rules behind a DOWN state; and
7. troubleshoot common WAF, TLS, redirect, HEAD/GET, and regional failures.

Prerequisites

You need:

• an UptimeRobot account;
• a public HTTP or HTTPS URL reachable from the internet;
• a clear definition of what “healthy” means for that URL;
• an alert contact or integration you can safely use for setup; and
• permission to create a temporary test monitor or use a non-production test endpoint if you want to validate failure notifications.

Avoid using a login page, checkout submission, or destructive endpoint as your first uptime target. A simple read-only health URL or a stable public page is easier to interpret.

Quick Answer

Open UptimeRobot, select + Add New Monitor, choose HTTP(s), enter the public URL, select the alert contact, choose the monitoring interval and region available to your account, then review Advanced Settings before saving. Verify that several checks report UP and inspect response history. If UptimeRobot reports false downtime, check the incident details, request method, redirect/status-code rules, timeout, TLS, WAF/rate limiting, and the region that reported the failure. Current UptimeRobot documentation says failed checks are retried before most DOWN transitions, with different retry timing for connection versus application failures. [1][3]

Step 1: Choose the Right URL to Monitor

For most websites, start with one of these:

• the public homepage if it accurately represents user availability; or
• a dedicated read-only health endpoint if your application exposes one and it checks the dependencies that matter.

A health endpoint is not automatically better. An endpoint that always returns 200 OK while the database, authentication service, or primary application path is broken gives false confidence.

Conversely, monitoring a heavyweight dynamic page can produce false incidents from slow third-party scripts or personalized behavior that is not essential to basic availability.

Define the monitor's question in one sentence, for example:

Can an external client reach the production website over HTTPS and receive the expected success response?

That definition will guide the status-code and redirect settings later.

Step 2: Create an HTTP(S) Monitor

In the current UptimeRobot dashboard:

1. open the Monitors page;
2. select + Add New Monitor or the current New action;
3. choose HTTP(s);
4. enter the target URL;
5. give the monitor a clear friendly name;
6. choose the alert contact(s);
7. choose the interval and monitoring region options available to your account; and
8. review advanced settings before selecting Create monitor. [1]

Use a friendly name that includes the environment and monitored outcome, such as:

Production website — HTTPS availability

Avoid vague names such as Site 1 once you operate more than a handful of monitors.

Step 3: Separate Monitoring Interval from Request Timeout

These are different settings.

• Monitoring interval controls how often UptimeRobot starts a check.
• Request timeout controls how long a single request may wait before it is considered unsuccessful. [2]

A short timeout can mark a slow-but-working site as unavailable. An excessively long timeout can delay detection of a genuinely unresponsive service.

Do not copy a timeout value from another website. Look at your normal server response time and choose a timeout that allows expected variance while still identifying behavior users would experience as a failure.

Plan-specific interval choices can change. Use the values available in your current dashboard instead of hard-coding a plan limit from an older tutorial.

Step 4: Review Request Method and Success Status Codes

UptimeRobot's advanced settings let you control HTTP request behavior, including accepted Up HTTP Status Codes and request details. [2]

Define success intentionally. For example:

• a normal application page may reasonably require a 2xx result;
• an intentionally redirecting HTTP URL may return 301 or 308 before HTTPS;
• a maintenance endpoint may have a different expected contract.

Do not simply mark every 3xx, 4xx, and 5xx response as “UP” to suppress alerts. That would make the monitor less capable of detecting application failures.

HEAD versus GET

UptimeRobot's current troubleshooting documentation says HTTP monitors default to a HEAD request and can switch to GET during retry behavior. Some servers reject HEAD with 403, 404, or 405, even though GET works normally. [3]

If incident details show this pattern, explicitly switch the monitor request method to GET in advanced settings rather than treating the website as down.

Step 5: Decide How Redirects Should Be Handled

The current advanced settings include Follow Redirections. When enabled, UptimeRobot follows HTTP redirects; when disabled, the redirect response can be evaluated directly. [2]

For a normal website canonicalization such as HTTP → HTTPS or www → apex, following redirects is usually closer to the user experience.

However, if your operational goal is specifically to verify that the redirect itself is configured, a dedicated monitor that evaluates the redirect response can be more useful.

Keep availability and redirect-policy tests separate when possible. One monitor should have one clear reason to fail.

Step 6: Configure Alert Contacts Conservatively

Choose the notification contact(s) that should receive incidents for this monitor. The current setup flow also allows notification delay/repetition configuration. [1]

During initial setup, do not route an unvalidated monitor to every on-call channel. Start with a safe recipient, verify that the monitor behaves correctly, then attach the production escalation path.

Your alert should identify:

• which URL failed;
• whether the issue was timeout, DNS, TLS, status code, or another known failure class;
• the monitoring region involved; and
• where an operator can check the incident history.

The first response should be diagnosis, not immediate configuration changes to the monitored website.

Step 7: Verify Several Successful Checks

After creating the monitor, wait for multiple checks and inspect the monitor history/statistics.

Confirm that:

• the current status is UP;
• the recent response times are plausible for the site;
• the expected region(s) are checking the service;
• the URL and redirect behavior are what you intended; and
• the monitor has not silently accepted an error status as healthy.

A single green check proves only that one request succeeded. Several consecutive checks are a better initial signal that the configuration is stable.

Step 8: Understand How UptimeRobot Confirms DOWN

As of the verification date, UptimeRobot's troubleshooting guide says a monitor is generally not marked DOWN after one failed check. [3]

Current documented behavior is:

• connection failures such as timeout, DNS failure, connection refused, or TLS errors are retried up to three times, 20 seconds apart;
• application failures such as an HTTP status outside the accepted success list or a keyword mismatch are retried up to three times, 10 seconds apart;
• SSL certificate errors are documented as an exception that can go directly to DOWN without the normal retries; and
• when a monitor is already DOWN, subsequent checks do not receive the same retry allowance before keeping it DOWN or returning it UP. [3]

These details can change, which is why this page carries a Last verified date. The operational lesson is durable: inspect the incident record and retry context instead of assuming that every DOWN state came from one isolated failed packet.

Verify the Setup

Consider the website monitor ready when:

1. the target URL represents a meaningful user-facing availability outcome;
2. multiple recent checks are UP;
3. accepted HTTP status and redirect behavior are intentional;
4. the timeout is reasonable for the site's normal response pattern;
5. notification contacts are correct; and
6. you understand how the monitor will behave when the endpoint actually fails.

For an end-to-end alert test, prefer a temporary test monitor aimed at a controlled endpoint that you can intentionally make fail. Do not take a production website offline just to validate notifications.

Common Problems and Fixes

Problem: UptimeRobot reports 403/404/405 but the page works in a browser

Likely cause: the server or WAF handles UptimeRobot's HEAD request differently from a normal browser GET.

Fix: inspect the incident details and try configuring the monitor to use GET explicitly. UptimeRobot documents HEAD-to-GET behavior as a common troubleshooting consideration. [3]

Problem: The monitor flaps between UP and DOWN

Likely causes: region-specific routing/CDN issue, autoscaling/restarts, rate limiting, short timeout, or intermittent upstream failure.

Fix: inspect the incident log and identify which region reported each failure. UptimeRobot specifically recommends looking for regional patterns when a monitor flaps. [3]

Do not hide a real regional failure by removing that region before checking whether customers in the same geography are affected.

Problem: A redirect is reported as failure

Likely cause: redirect following is disabled or the accepted status-code list does not match the intended behavior.

Fix: decide whether the monitor is testing the final destination or the redirect itself, then configure Follow Redirections and success statuses accordingly. [2]

Problem: The website is slow but not technically DOWN

If availability is healthy but latency is important, use UptimeRobot's slow-response alert capability or a separate performance-oriented monitor rather than distorting the availability timeout until slow responses become fake outages. The advanced settings documentation distinguishes slow-response alerting from request timeout. [2]

Problem: UptimeRobot is blocked by a WAF or rate limiter

Fix: verify the incident source, request behavior, and current UptimeRobot probe information before adding allow rules. If you allow monitoring probes, scope the rule as narrowly as your security model permits. Do not disable a WAF globally because an uptime check is blocked.

Problem: TLS errors immediately create DOWN incidents

Current UptimeRobot troubleshooting documentation identifies SSL certificate errors as an exception to normal retry behavior. [3]

Inspect certificate validity, hostname/SNI matching, trust chain, and CDN/origin configuration. Do not simply widen the list of accepted HTTP statuses; a TLS failure happens before normal HTTP status evaluation.

Best Practices

Monitor a meaningful outcome. The endpoint should represent something users need, not merely a process that can return 200 while the product is broken.

Keep checks non-destructive. Availability requests should not create orders, send email, mutate data, or consume expensive resources.

Do not over-alert during setup. Validate the monitor with a safe contact before attaching a full escalation chain.

Use separate monitors for separate contracts. Availability, redirect correctness, SSL expiry, response-time thresholds, and API semantic health are different questions.

Review false positives rather than suppressing them blindly. A false incident can reveal a HEAD-handling bug, regional CDN issue, rate limit, or WAF rule that may also affect real clients.

Recheck volatile settings. Intervals and feature availability can be plan-dependent. Avoid building runbooks around old screenshots or pricing tables.

When This Setup Makes Sense

Use an HTTP(S) monitor when the main question is whether an external client can reach a web endpoint and receive an acceptable HTTP result.

If you need to validate fields inside a JSON response, authentication behavior, headers, or semantic API health, use the companion How to Monitor an API with UptimeRobot tutorial instead.

For broader context, see the UptimeRobot software profile, uptime monitoring guide, uptime monitoring category, and UptimeRobot vs Pingdom comparison.

FAQ

Which UptimeRobot monitor type should I use for a website?

For ordinary website availability, start with HTTP(s). Use Keyword only when content presence is itself the health contract, and use API Monitoring when you need structured response assertions beyond HTTP reachability. [1][4]

What HTTP status codes should count as UP?

Only the statuses that genuinely represent success for the endpoint you are monitoring. A normal application endpoint usually should not consider arbitrary 4xx or 5xx responses healthy merely to reduce alerts.

Why does UptimeRobot report downtime when the site works in my browser?

Check the incident details for region, request method, TLS/DNS failure, status code, timeout, WAF/rate-limit behavior, and redirects. UptimeRobot's current docs specifically call out servers that reject HEAD requests while browser GET requests succeed. [3]

Conclusion

A useful UptimeRobot website monitor is a small external contract: a particular URL, requested in a defined way, must produce an acceptable result within a reasonable time. Configure that contract explicitly, verify multiple successful checks, understand the retry model, and test notifications without breaking production.

That creates an uptime signal you can trust instead of a green badge that has never been challenged or a noisy alert that operators learn to ignore.

References

1. UptimeRobot Help Center — How to Create Your First Monitor on UptimeRobot – Quick Setup Guide — https://help.uptimerobot.com/en/articles/11358364-how-to-create-your-first-monitor-on-uptimerobot-quick-setup-guide — published July 31, 2026; accessed September 10, 2026.
2. UptimeRobot Help Center — UptimeRobot Advanced Settings – Customize Your Monitor Configuration — https://help.uptimerobot.com/en/articles/11360863-uptimerobot-advanced-settings-customize-your-monitor-configuration — published February 25, 2026; accessed September 10, 2026.
3. UptimeRobot Help Center — How to Debug a Monitor Showing as Down in UptimeRobot — https://help.uptimerobot.com/en/articles/11358466-how-to-debug-a-monitor-showing-as-down-in-uptimerobot — published July 31, 2026; accessed September 10, 2026.
4. UptimeRobot Help Center — Understanding UptimeRobot Monitor Types: A Guide to Essential Services — https://help.uptimerobot.com/en/articles/11358441-understanding-uptimerobot-monitor-types-a-guide-to-essential-services — published July 31, 2026; accessed September 10, 2026.

Editorial note: This tutorial was fact-checked against current UptimeRobot documentation. No production website was intentionally taken offline and no live UptimeRobot account was used to claim hands-on test results.