Frequently asked questions

Most monitors are HTTP or HTTPS requests sent on the interval you set. By default a response in the 200 to 299 range counts as up, and any other status code, a connection error, or a request that does not finish within 10 seconds counts as a failed check. You are not limited to the status code: response assertions let a monitor judge the body, a header, or a JSON field as well, so an endpoint that answers 200 while carrying an error can still be marked down. Heartbeat monitors are the inverse: your own application or cron job sends a request to a RealUptime URL on its own schedule, and RealUptime marks the monitor down if the expected ping does not arrive within the grace period you set.

A single failed check does not trigger a down state or an alert. A region flips to down after two consecutive failed checks from that region, and flips back to operational after one successful check. That short delay filters out one-off network blips while still catching a real outage fast.

You choose the interval per monitor, from once a minute up to once a day. Free and Growth run as fast as once a minute; Scale runs as fast as once every 30 seconds.

Each monitor checks from up to ten regions: US-East, US-West, Europe, Asia-Pacific, US-Central, Canada, UK, Southeast Asia, Australia, and South America. A status page that only checks from one place can read all green while a region-specific outage, a bad deploy that only breaks your European traffic, for example, is actively affecting real customers. Showing ten independent region readings side by side, disagreement included, is what a single-location check cannot do. You can choose which of the ten regions apply to a given monitor.

Degraded means some but not all of a monitor's regions are reporting down at the same time, for example Europe failing while the other three are fine. It is a distinct, honest state from a full outage, and it is why regional readings are shown individually rather than collapsed into one badge.

Yes. Response assertions let a monitor judge itself on four things, and you can set any of them, all of them, or none. The body, which must contain or not contain a literal string. A named response header, which must equal or contain a value. An explicit status range that replaces the default 200 to 299 rule, so a check can require the 401 an auth-protected endpoint is supposed to return. And a JSON field addressed by path, which must equal a value, contain it, or simply exist. A failed assertion counts the check as down and names the specific reason on the monitor's row, so you learn which assertion broke rather than only that something did. Body matching is a literal string rather than a regular expression, deliberately: a customer-supplied pattern evaluated inside the probe fleet on every check is a performance risk we are not willing to run against everyone else's monitors.

Yes, with a multi-step monitor. Give it up to 10 ordered requests and RealUptime runs them in sequence with a cookie jar carried from each response into the next, so the session a login step establishes is available to the steps after it. Every step can carry its own assertions. The first step to fail ends the run and names itself, so you find out which stage of the journey broke, not just that the journey did. A multi-step monitor counts as one monitor against your plan's allowance.

Yes, on the Scale plan. A browser check runs your flow in headless Chromium: open a page, click, fill a field, wait for an element, assert that some text or element is present, and capture a screenshot of what actually rendered. That catches what a request-level check cannot, like a page that returns a healthy status code and then renders blank, or a submit button that never becomes usable because a script failed. Browser checks run from US-East, as often as every 5 minutes, up to 10 per account.

Possibly both, and your errors are the evidence to trust first. A status page is a claim updated by people during an incident, so it lags, and a component board can stay green while a banner admits a problem. A single-location health check behind it can also read all green while one region is genuinely broken. When what you see disagrees with what a status page says, verify with a measurement: load the service from another network if you can, and check a tracker that probes the service itself from multiple regions rather than repeating what the vendor has posted.

The free plan includes 1 status page and 10 monitors, checked as often as once a minute from any of the ten regions, with account-email alerts plus up to 5 notification channels of your choice. There is no trial period or credit card requirement to start.

Free plans are a hard limit of 10 monitors: the dashboard asks you to upgrade or remove a monitor first, and a free account can never generate a bill. Growth includes 25 and Scale includes 150. Paid plans are a hard limit too until overage pricing is turned on. Monitors you already have keep running normally, nothing is paused or deleted for being over a limit you were previously under.

Free includes 1 status page. Growth and Scale are unlimited: give each product, brand, or audience its own page, each with its own branding, domain, and subscriber list. There is no per-page charge; a scripted burst of new pages is rate-limited, not billed.

Yes, on Growth and Scale. Each calendar month gives you one record per monitor: uptime, downtime, how many incidents were open, and average and p95 response time, broken out by region and pooled. Download it as a CSV or print it to a PDF. Every figure states how much of the month it actually measured, so a monitor you added mid-month is reported against the days it existed rather than rounded up to a full month. Your checks are recorded on every plan, so upgrading opens the months already measured, not just the ones ahead.

We do not currently offer a contractual uptime service-level agreement. Our own status page is public at status.realuptime.io, so you can check our real track record rather than take a claim on faith.

Visitors to your public status page can enter their email to subscribe to incident updates for that page. They confirm by email (double opt-in) before notifications start, and every notification email includes a one-click unsubscribe link. Subscriber notifications are built in on every plan, including Free, not an add-on.

Operator-facing alerts (for you, not your status page's subscribers) go to your account email automatically on every down and recovery transition. From the Notifications section you can add Slack, a signed outgoing webhook, PagerDuty, Discord, Microsoft Teams, Opsgenie, incident.io, FireHydrant, or a Zapier and generic JSON hook, on any plan including Free. Every channel fires on the same transitions and respects the same scheduled-maintenance suppression, and each one can be tested before you rely on it. Growth and Scale add escalation policies, so an alert nobody acknowledges moves to the next person or channel on a schedule you set. There is no native SMS or phone-call paging yet; route through PagerDuty or Opsgenie if you need a phone to ring.

Custom domains with automatic TLS are available on the Growth and Scale plans. Point a CNAME at the address we give you and we handle certificate issuance and renewal, no manual certificate upload.

Open Billing from your account settings to reach the billing portal, where you can cancel any time. Cancellation stops future renewals and takes effect at the end of the period you already paid for; you keep paid-tier access until then.

You can request a full refund of your first payment on a plan within 14 days of that charge, for any reason, no questions asked. After that window, refunds cover verifiable issues with the service, for example monitoring that did not run as configured. Contact support; within the 14-day window we refund without asking you to reproduce anything. Read the full policy on the Terms page.

Yes. Your data section in account settings exports a JSON file containing your account details, monitors, status pages, incidents, subscribers, and uptime history, available any time, not only before you cancel.

Account deletion is immediate, not a grace period: it cancels any active subscription right away, then permanently deletes your account and everything tied to it, monitors, status pages, incidents, subscribers, and API keys included. There is no recovery after deletion, so export your data first if you might want it later.

Yes, with one difference between the two: the MCP server gives every account, free included, read-only access to list monitors, check status, and read incidents, while the REST API and full read-write access on either surface are both Growth and Scale plan features. Generate an API key from account settings; free plans are limited to read-only keys. Full reference docs are linked from the API's own root endpoint.