# RealUptime > RealUptime is four products, sold to the same developer and small-company customer instead of four separate markets. RealUptime Status is a B2B status-page and incident-communication product for telling your own customers the truth about an outage. RealUptime Monitor is private multi-region uptime and server-health monitoring, billed separately from Status. RealUptime Errors is application error tracking with grouped issues, releases, and honest drop counts. RealUptime Outages is a free, public outage tracker that is the funnel for the other three, not a business meant to sustain itself independently. Pricing on the paid products is flat-rate, not metered per subscriber or per check. Most status pages run health checks from a single location and collapse the result into one badge, so a regional-only outage (a bad deploy that only breaks one region, a CDN edge node failing in one place) can leave a status page showing "all systems operational" while customers in that region are broken. RealUptime Status checks from ten named regions (US-East, US-West, Europe, Asia-Pacific, US-Central, Canada, UK, Southeast Asia, Australia, South America) and shows each region's state separately on the public status page instead of collapsing them into a single badge. How many of those ten a monitor may use is set by the plan: four on Free (US-East, US-West, Europe, Asia-Pacific), eight on Pro, all ten on Business. ## Product - [Homepage](https://realuptime.io/): product overview and pricing. - [Pricing](https://realuptime.io/pricing): Free, Pro, Business, and the MSP plan for agencies ($199/mo, 450 monitors pooled across an organization, everything in Business on every client account), flat rate, no per-subscriber tiers. - [MSP plan](https://realuptime.io/msp): the dedicated landing page for the MSP plan for agencies and MSPs, with the pooled-allowance model, client accounts, and MSP pricing. - [About](https://realuptime.io/about): what RealUptime Status is and why it exists. - [Careers](https://realuptime.io/careers): open roles at RealUptime and how to apply. - [How we work](https://realuptime.io/how-we-work): how the team makes decisions, talks, spends its time, gets paid and treats each other. - [Technical co-founder and CTO](https://realuptime.io/careers/technical-cofounder-cto): All four products are live. They need someone who makes them better every week, from the database migration to the page a customer sees. - [Founding account executive](https://realuptime.io/careers/founding-account-executive): People sign up for RealUptime every week. Your job is to turn that into paying customers, then into a business that grows on its own. - [Founding marketing lead](https://realuptime.io/careers/founding-marketing-lead): People already find the Outages pages through search. Your job is to turn that into a steady stream of the right visitors, and those visitors into signups. - [Jose Franco, author](https://realuptime.io/authors/jose-franco): the founder's profile and the articles he has written for RealUptime. - [No lock-in](https://realuptime.io/no-lock-in): export every account's monitors, status pages, incidents, subscribers, and API keys (metadata only) in open JSON or CSV formats, on demand, from account settings. - [Status pages](https://realuptime.io/status): the public status-page product. - [Status page examples](https://realuptime.io/status-page-examples): four status page templates built on RealUptime, for a SaaS API, an online store, an agency with multiple clients, and an open source project. Clone one to start your own. - [Uptime monitoring](https://realuptime.io/monitor): the private multi-region monitoring product. - [Error tracking](https://realuptime.io/errors): application error tracking with grouped issues, releases, and honest drop counts. Does not watch cron jobs or background workers for silence; that is [heartbeat monitoring](https://docs.realuptime.io/heartbeats) in RealUptime Monitor, a separate billable product. - [Why status pages lie](https://realuptime.io/why-status-pages-lie): the regional-monitoring thesis explained in full. - [FAQ](https://realuptime.io/faq): plans, regions, billing, and API access. - [Integrations](https://realuptime.io/integrations): all ten alerting channels (operator email, Slack, signed webhooks, PagerDuty, Discord, Microsoft Teams, Opsgenie, incident.io, FireHydrant, Zapier or generic JSON), the status-page badge and embed, the REST API, the MCP server, and the GitHub Action. - [Check recipes](https://realuptime.io/recipes): one-click monitor configurations (Stripe webhook endpoint, Supabase REST/Auth/Postgres, Postgres, MySQL, nightly backup heartbeat, outbound mail, DNS apex record) that prefill the add-check form with a real check type, assertions, and interval. - [Outage tracker](https://realuptime.io/outages): our check readings for 946 popular services, with the vendor's own status beside them. - Business services most often asked about, each with its live status page: [AWS (Amazon Web Services)](https://realuptime.io/outages/aws), [GitHub](https://realuptime.io/outages/github), [Stripe](https://realuptime.io/outages/stripe), [Cloudflare](https://realuptime.io/outages/cloudflare), [OpenAI](https://realuptime.io/outages/openai), [Slack](https://realuptime.io/outages/slack), [Vercel](https://realuptime.io/outages/vercel), [Twilio](https://realuptime.io/outages/twilio), [Datadog](https://realuptime.io/outages/datadog), [Microsoft Azure](https://realuptime.io/outages/azure), [Google Cloud Platform](https://realuptime.io/outages/google-cloud), [Snowflake](https://realuptime.io/outages/snowflake), [Supabase](https://realuptime.io/outages/supabase), [Render](https://realuptime.io/outages/render), [Fly.io](https://realuptime.io/outages/fly-io). - [Outage tracker methodology](https://realuptime.io/outages/methodology): how the outage tracker's checks work. - [Data access for press and researchers](https://realuptime.io/outages/data-access): the public keyless JSON endpoints, their per-IP rate limit, and how to cite a reading (the API's own `source.attribution` string is "Measured by RealUptime. Source: "). - [Corrections and retractions](https://realuptime.io/outages/corrections): every probe event we have retracted, with what we originally showed, why it was retracted, and when. Events that fail our rules are retracted, kept, and listed here. - [Is the internet down?](https://realuptime.io/outages/internet): shared-infrastructure incidents (Cloudflare, AWS regions, CDNs) inferred from the incidents vendors report on their own status pages and RealUptime's own checks across every tracked service, plus the map of which services answer from behind which provider. - [Outage research](https://realuptime.io/outages/research): rapid write-ups of probe events and uptime reports from the tracker's own check readings; every piece states its measurement window, methodology version and coverage age. - [Status page lag](https://realuptime.io/outages/research/status-page-lag): per service, the time between our checks first failing from two or more regions and the vendor's status page posting the incident, only where both records exist, with the method and a CSV. - [Uptime leaderboards](https://realuptime.io/outages/leaderboards): one ranked page per catalog category ranking services by uptime by our checks over a trailing 90-day window; a category ranks only once at least three of its services have a full quarter of coverage, and says so otherwise. A service whose status page we read is listed apart as not ranked, because its record is the vendor's own incident reports and not our checks. These figures come from our own checks of one public endpoint per service. They are not the service's real uptime. Same readings as the research section's league tables, never a paid placement or a recommendation. Per category: https://realuptime.io/outages/leaderboards/cloud-dev-infra (cloud and dev infra), https://realuptime.io/outages/leaderboards/social-communication (social and communication), https://realuptime.io/outages/leaderboards/payments (payments), https://realuptime.io/outages/leaderboards/gaming (gaming), https://realuptime.io/outages/leaderboards/consumer (consumer), https://realuptime.io/outages/leaderboards/other (other). - [Incidents vendors declared, month by month](https://realuptime.io/outages/monthly): one page per month that has ended, listing the incidents the tracked services declared on their own status pages, with the vendor's own counts and times. Nothing on these pages comes from our checks. - [Internet weather](https://realuptime.io/outages/internet-weather): per-region p50/p95/p99 check latency across the public outage catalog, against each region's 7-day baseline; from RealUptime's own checks, never customer traffic. JSON at https://realuptime.io/api/v1/outages/internet-weather, Atom at https://realuptime.io/outages/internet-weather/feed.atom. - [Build your stack](https://realuptime.io/outages/stack): one combined page for the services you depend on, plus an alert: you hear when one of them reports an incident on its own status page, and again when it reports it resolved; for a service with no status feed we can read, when our checks of it fail from two or more distant regions, and again when they pass; no account. - Per-service history: https://realuptime.io/outages//history, one page per indexable tracked service (same eligibility as the live page). 90-day share of checks passed by region, a month-by-month uptime-by-our-checks table, and the probe event log; a service tracked less than 90 days shows only the days it has and says so. - Localized outage pages: https://realuptime.io/outages//l/, Spanish, Portuguese and German chrome translations of the live page above (locale codes es, pt, de), same eligibility. Vendor names and check readings are never translated; hreflang alternates link every language version, including x-default back to the English page. - Per-country outage pages: https://realuptime.io/outages//in/, answering "Is down in the UK?" from the check that actually runs from that country. There are eight countries, exactly the ones RealUptime holds a probe in: us (Ashburn, San Jose, Chicago), de (Frankfurt), jp (Tokyo), ca (Toronto), uk (London), sg (Singapore), au (Sydney), br (Sao Paulo). A country with no probe of ours has no page, however often it is searched: there is no India page and no Pakistan page, because a page named after a country we do not measure from would be a fabrication. Each page states that country's check reading now and over the last 24 hours, with the city named, then how the other regions read for contrast. Same eligibility as the live page; canonical points at itself and hreflang en- alternates link the parent and the sibling countries, so a country page never competes with the parent for the bare "is X down". - [Embeddable status badge](https://realuptime.io/outages/badge): copy-paste HTML and Markdown snippets for the live per-service SVG badge at https://realuptime.io/outages//badge.svg, plus a live preview. Free, no account; the badge shows no color when we have no recent reading (stale and no-data are their own states). - [Compare services by our checks](https://realuptime.io/outages/compare): curated head-to-head pairs (e.g. Stripe vs Adyen) at https://realuptime.io/outages/compare/-vs-, whether our checks pass or fail now and 12 months of uptime by our checks for each side, factual only, never a recommendation of one vendor over the other. These figures come from our own checks of one public endpoint per service. They are not the service's real uptime. Any two active catalog services compare on request, not only the curated pairs listed on the index. - [AI API error codes](https://realuptime.io/outages/api-errors): OpenAI, Anthropic and Gemini API errors (429, 500, 503, 529), each with the provider's own meaning, whether it usually comes from the caller's account or the provider, the fix, and our live check reading of that API beside the provider's own status. Our checks cannot see an account's limits or load on one model, and the pages say so. - [OpenAI error 429: You exceeded your current quota](https://realuptime.io/outages/api-errors/openai-429-insufficient-quota) - [OpenAI error 429: Rate limit reached](https://realuptime.io/outages/api-errors/openai-429-rate-limit) - [OpenAI error 500: The server had an error while processing your request](https://realuptime.io/outages/api-errors/openai-500) - [OpenAI error 503: The engine is currently overloaded](https://realuptime.io/outages/api-errors/openai-503) - [Anthropic error 529: overloaded_error](https://realuptime.io/outages/api-errors/anthropic-529-overloaded) - [Anthropic error 429: rate_limit_error](https://realuptime.io/outages/api-errors/anthropic-429-rate-limit) - [Gemini API error 503: The model is overloaded](https://realuptime.io/outages/api-errors/gemini-503-unavailable) - [Gemini API error 429: RESOURCE_EXHAUSTED](https://realuptime.io/outages/api-errors/gemini-429-resource-exhausted) - [MCP server](https://realuptime.io/mcp): query our live check readings from Claude or any MCP client, no API key for the outage tools. Marketing landing; full technical reference at https://docs.realuptime.io/mcp. - [Set up with your AI agent](https://realuptime.io/agents): one prompt to paste into Claude Code, Cursor, Codex or Copilot; the agent creates monitors, heartbeats, a status page and its components, an Errors project and alert destinations within the Free plan, with CLI commands it runs itself. The prompt as plain text: https://realuptime.io/agents/prompt.txt. - [Regional reliability report](https://realuptime.io/reports/regional-reliability): our own check readings of 946 services from ten regions; the share of checks that passed barely varies, latency more than doubles. - [Free tools](https://realuptime.io/tools): no-signup tools built on RealUptime's own checks and SLA math. - [Is my website down?](https://realuptime.io/tools/is-it-down): free live check of any URL, no signup. - [SLA / uptime calculator](https://realuptime.io/tools/sla-calculator): enter any uptime target and see the downtime it allows per day, week, month, and year, plus SLO error budget remaining, burn rate and multiwindow burn-rate alert thresholds. - [99% uptime calculator](https://realuptime.io/tools/sla-calculator/99): downtime allowed per month/year at 99% ("two nines") uptime. - [99.5% uptime calculator](https://realuptime.io/tools/sla-calculator/99-5): downtime allowed per month/year at 99.5% uptime. - [99.9% uptime calculator](https://realuptime.io/tools/sla-calculator/99-9): downtime allowed per month/year at 99.9% ("three nines") uptime. - [99.95% uptime calculator](https://realuptime.io/tools/sla-calculator/99-95): downtime allowed per month/year at 99.95% uptime. - [99.99% uptime calculator](https://realuptime.io/tools/sla-calculator/99-99): downtime allowed per month/year at 99.99% ("four nines") uptime. - [99.999% uptime calculator](https://realuptime.io/tools/sla-calculator/99-999): downtime allowed per month/year at 99.999% ("five nines") uptime. - [Downtime cost calculator](https://realuptime.io/tools/downtime-cost-calculator): estimate what downtime costs using your own monthly revenue. - [Cron job monitor](https://realuptime.io/tools/cron-monitor): a heartbeat ping URL for a cron job with no signup, from the page or by POST to https://realuptime.io/api/heartbeat/new; counts pings for seven days, and claiming it by email turns it into a heartbeat monitor that alerts on a missed run. - [SSL certificate checker](https://realuptime.io/tools/ssl-checker): free certificate expiry, lifetime, issuer, and days-remaining lookup. - [Health check endpoint tester](https://realuptime.io/tools/health-endpoint-tester): free grade of a health endpoint's status code, latency, body and cache headers. - [DNS propagation checker](https://realuptime.io/tools/dns-propagation): resolve an A, AAAA, CNAME, MX, NS or TXT record from every probe region and see which answers differ, with a shareable result link. - [Ping from multiple locations](https://realuptime.io/tools/ping): round-trip time and loss to a host from every probe region, measured by TCP connect to port 443, 80 or 22 (not ICMP). - [TTFB test](https://realuptime.io/tools/ttfb): DNS, connect, TLS and time-to-first-byte for a URL from every probe region. - [On-call schedule generator](https://realuptime.io/tools/on-call-schedule): build a daily or weekly on-call rotation in any time zone and download it as iCal or CSV; runs in the browser. - [Metered pricing cost calculator](https://realuptime.io/tools/cost-calculator): compares Atlassian Statuspage's published per-subscriber pricing to RealUptime's flat rate, for a given subscriber and monitor count. - [Status page grader](https://realuptime.io/tools/status-page-grader): free report card for any status page URL, graded on regional visibility, incident history depth, and incident cadence from deterministic rules, no AI and no signup. Adds a claimed-vs-observed comparison against RealUptime's own probe data for vendors we already track. - [Sentry pricing calculator](https://realuptime.io/tools/sentry-pricing-calculator): enter a monthly error volume and a retention window, see which published Sentry plan covers it beside RealUptime Errors' flat rate. Sentry figures read October 5, 2026. - [Statuspage pricing calculator](https://realuptime.io/tools/statuspage-pricing-calculator): enter subscribers, team members and page type, see which published Atlassian Statuspage plan covers it and its price beside RealUptime Status. Statuspage figures read October 5, 2026. ## Comparisons - [All comparisons](https://realuptime.io/vs): every competitor, side by side. - [vs Statuspage](https://realuptime.io/vs/statuspage): Statuspage alternative, feature comparison. - [vs Better Stack](https://realuptime.io/vs/better-stack): Better Stack alternative, feature comparison. - [vs Instatus](https://realuptime.io/vs/instatus): Instatus alternative, feature comparison. - [vs UptimeRobot](https://realuptime.io/vs/uptimerobot): UptimeRobot alternative, feature comparison. - [vs OpenStatus](https://realuptime.io/vs/openstatus): OpenStatus alternative, feature comparison. - [vs Pingdom](https://realuptime.io/vs/pingdom): Pingdom alternative, feature comparison. - [vs Hyperping](https://realuptime.io/vs/hyperping): Hyperping alternative, feature comparison. - [vs Checkly](https://realuptime.io/vs/checkly): Checkly alternative, monitoring comparison. - [vs Cronitor](https://realuptime.io/vs/cronitor): Cronitor alternative, monitoring comparison. - [vs StatusCake](https://realuptime.io/vs/statuscake): StatusCake alternative, feature comparison. - [vs Freshping](https://realuptime.io/vs/freshping): Freshping shut down in 2026; where a former Freshping user goes next. - [vs Freshstatus](https://realuptime.io/vs/freshstatus): Freshstatus shut down March 31, 2026; where a former Freshstatus user goes next. - [vs Opsgenie](https://realuptime.io/vs/opsgenie): Opsgenie support ends April 5, 2027; what an alerting team needs next. - [vs PagerDuty](https://realuptime.io/vs/pagerduty): PagerDuty alternative for small teams, flat-priced checks and on-call compared with per-user paging. - [vs HetrixTools](https://realuptime.io/vs/hetrixtools): HetrixTools alternative, uptime-monitoring comparison. - [vs Sentry](https://realuptime.io/vs/sentry): Sentry alternative, flat-priced error tracking comparison. - [vs Rollbar](https://realuptime.io/vs/rollbar): Rollbar alternative, flat-priced error tracking comparison. - [vs Bugsnag](https://realuptime.io/vs/bugsnag): Bugsnag (Insight Hub) alternative, error tracking comparison. - [vs GlitchTip](https://realuptime.io/vs/glitchtip): GlitchTip alternative, hosted error tracking comparison. - [vs Downdetector](https://realuptime.io/vs/downdetector): Downdetector alternative, measured outage tracking with published methodology. - [vs StatusGator](https://realuptime.io/vs/statusgator): StatusGator alternative, independent probing vs status-page aggregation. - [vs IsDown](https://realuptime.io/vs/isdown): IsDown alternative, measured outage tracking comparison. - [vs Uptime Kuma](https://realuptime.io/vs/uptime-kuma): Uptime Kuma alternative, self-hosted vs hosted monitoring compared honestly. - [vs Status.io](https://realuptime.io/vs/status-io): Status.io alternative, status pages with built-in monitoring. - [vs Healthchecks.io](https://realuptime.io/vs/healthchecks-io): Healthchecks.io alternative, heartbeats plus active uptime checks. - [vs Pulsetic](https://realuptime.io/vs/pulsetic): Pulsetic alternative, uptime-monitoring comparison. - [vs Phare](https://realuptime.io/vs/phare): Phare alternative, flat plans vs usage-based monitoring events. - [vs OneUptime](https://realuptime.io/vs/oneuptime): OneUptime alternative, focused products vs one open-source platform. - [vs Site24x7](https://realuptime.io/vs/site24x7): Site24x7 alternative, focused uptime monitoring vs the full suite. - [vs Bugsink](https://realuptime.io/vs/bugsink): Bugsink alternative, hosted error tracking comparison. - [vs Cronhub](https://realuptime.io/vs/cronhub): Cronhub shut down in June 2026; RealUptime Monitor replaces its heartbeat-monitoring half and does not replace its job-scheduler half. - [vs Raygun](https://realuptime.io/vs/raygun): Raygun alternative, one flat-priced error tracker compared with a three-product observability suite that has no free tier. - [UptimeRobot vs Pingdom](https://realuptime.io/vs/uptimerobot-vs-pingdom): two competitors compared directly, sourced and dated. - [Status.io vs Statuspage](https://realuptime.io/vs/status-io-vs-statuspage): the two long-established status-page products compared directly, sourced and dated. - [GlitchTip vs Bugsink](https://realuptime.io/vs/glitchtip-vs-bugsink): two Sentry-SDK-compatible error trackers compared directly, sourced and dated. - [Uptime Kuma vs UptimeRobot](https://realuptime.io/vs/uptime-kuma-vs-uptimerobot): self-hosted free software against a hosted free plan, compared directly, sourced and dated. - [Migrate from Pingdom](https://realuptime.io/migrate/pingdom): step-by-step export, import, and check-type mapping. - [Migrate from Freshping](https://realuptime.io/migrate/freshping): Freshping is gone; what a former user does next. - [Migrate from Statuspage](https://realuptime.io/migrate/statuspage): subscriber CSV export/import and page setup, off subscriber-count pricing tiers. - [Migrate from Instatus](https://realuptime.io/migrate/instatus): subscriber CSV export/import and page setup, onto regions shown together instead of rotated. - [Migrate from UptimeRobot](https://realuptime.io/migrate/uptimerobot): live API-key import of HTTP monitors, plus what the importer flags for a hand rebuild. - [Migrate from Opsgenie](https://realuptime.io/migrate/opsgenie): import heartbeats, on-call schedules and escalation policies with one API key before Opsgenie shuts off on April 5, 2027. - [Migrate from Uptime Kuma](https://realuptime.io/migrate/uptime-kuma): upload a Kuma 1.x backup or the 2.x /metrics page; HTTP, keyword, TCP, DNS and push monitors come across. - [Migrate from Cachet](https://realuptime.io/migrate/cachet): paste a Cachet 2.x address; its components and groups come across from Cachet's public API. - [Migrate from Upptime](https://realuptime.io/migrate/upptime): upload .upptimerc.yml; HTTP and TCP sites become checks run from fixed regions instead of a CI schedule. - [Migrate from Gatus](https://realuptime.io/migrate/gatus): upload config.yaml; HTTP, TCP and DNS endpoints and heartbeat external endpoints come across. - [Migrate from Grafana OnCall](https://realuptime.io/migrate/grafana-oncall): OnCall OSS was archived March 24, 2026; import its schedules and escalation chains with one API token. - [Migrate from Better Stack](https://realuptime.io/migrate/better-stack): live API-token import of HTTP monitors, with a type-by-type mapping. - [Migrate from Cronitor](https://realuptime.io/migrate/cronitor): live API-key import of HTTP checks; jobs and heartbeats recreated as RealUptime heartbeats. - [Migrate from Checkly](https://realuptime.io/migrate/checkly): live API-key import of URL monitors and GET API checks across every account the key can see, with a type-by-type mapping. - [Migrate from StatusCake](https://realuptime.io/migrate/statuscake): live API-key import of HTTP and HEAD tests, and which other test types map to RealUptime checks. - [Migrate from Cronhub](https://realuptime.io/migrate/cronhub): Cronhub's data was deleted June 30, 2026; rebuilding heartbeats, and what to do about the scheduler half. - [Migrate from Freshstatus](https://realuptime.io/migrate/freshstatus): rebuilding the status page after the March 31, 2026 shutdown, and importing the subscriber list from the archive Freshworks emailed. ## Guides - [All guides](https://realuptime.io/guides): status pages, incident communication, and uptime monitoring. - [Status page best practices](https://realuptime.io/guides/status-page-best-practices): what to publish, when, and how to stay honest. - [Incident communication templates](https://realuptime.io/guides/incident-communication-templates): what to say at each stage, with copy-paste templates. - [Uptime monitoring explained](https://realuptime.io/guides/uptime-monitoring-explained): what a green badge measures, and what it hides. - [Monitoring status meanings](https://realuptime.io/guides/monitoring-status-meanings): operational, down, blocked, and the other real states. - [Choosing a status page tool](https://realuptime.io/guides/choosing-a-status-page-tool): a factual evaluation checklist. - [Is Downdetector accurate?](https://realuptime.io/guides/how-downdetector-works): where crowd-reported outage data comes from, its biases, and how to compare sources during an incident. - [47-day SSL certificates](https://realuptime.io/guides/47-day-certificates): the 200, 100 and 47 day lifetime dates, what breaks, and how to catch a failed renewal. - [Health check endpoints](https://realuptime.io/guides/health-check-endpoints): shallow and deep checks, liveness and readiness, what to return and what to leave out. - [Postmortem template](https://realuptime.io/guides/postmortem-template): a blameless postmortem template in Markdown, Confluence and Google Docs form, with a filled example. - [Browser noise errors](https://realuptime.io/browser-errors): ResizeObserver loop, Script error., Non-Error promise rejection, ChunkLoadError and extension errors, what each means and how to filter it. - [ResizeObserver loop limit exceeded](https://realuptime.io/browser-errors/resizeobserver-loop-limit-exceeded): what it means, whether it is a bug, and the filter. - [Script error.](https://realuptime.io/browser-errors/script-error): what it means, whether it is a bug, and the filter. - [Non-Error promise rejection captured](https://realuptime.io/browser-errors/non-error-promise-rejection): what it means, whether it is a bug, and the filter. - [ChunkLoadError](https://realuptime.io/browser-errors/chunkloaderror): what it means, whether it is a bug, and the filter. - [Errors from browser extensions](https://realuptime.io/browser-errors/browser-extension-errors): what it means, whether it is a bug, and the filter. - [Self-hosted Sentry requirements](https://realuptime.io/guides/self-hosted-sentry-requirements): the documented RAM, disk and container count, upgrade hard stops, and the hosted alternative. - [GitHub Actions schedule not running](https://realuptime.io/guides/github-actions-schedule-not-running): why scheduled workflows are delayed, dropped or disabled, and the heartbeat step that alerts on a missed run. - [Watch Uptime Kuma from outside](https://realuptime.io/guides/watch-uptime-kuma-from-outside): the one free outside check, HTTP or heartbeat, that alerts when Kuma itself goes down. - [Crashlytics for web apps](https://realuptime.io/guides/crashlytics-for-web): why Firebase Crashlytics has no web SDK, and how to keep it for mobile while browser errors go to Errors. - [Firebase web error tracking](https://realuptime.io/guides/firebase-web-error-tracking): Sentry's SDK on Firebase Hosting and Cloud Functions, pointed at Errors, with source maps and alerts. - [NIS2 Article 23 incident notification](https://realuptime.io/guides/nis2-incident-notification): the Directive's text on notifying service recipients and authorities, mapped to status page and monitoring records; not legal advice. - [DORA incident reporting](https://realuptime.io/guides/dora-incident-reporting): Articles 14, 19 and 28 and the 2025/301 time limits, mapped to status page, monitoring and vendor records; not legal advice. - [SOC 2 availability and vendor monitoring evidence](https://realuptime.io/guides/soc-2-availability-monitoring): A1.1, A1.2, CC2.3, CC7.2, CC7.4 and CC9.2 quoted and mapped to monitoring records and exports; not audit advice. ## Blog - [Blog](https://realuptime.io/blog): notes from the team on uptime, incidents, and building RealUptime, published every few days. - [When the monitor is the problem](https://realuptime.io/blog/when-the-monitor-is-the-problem): the probe failure-mode register as public content: silent failures, who finds out, and what we deliberately do not defend. - [Uptime monitor false positives: the page you should not have gotten](https://realuptime.io/blog/the-page-you-should-not-have-gotten): how a failure must persist for 3 minutes before a region is called down and anyone is paged, and why "we could not check" never counts as your downtime. - [RealUptime is public](https://realuptime.io/blog/realuptime-is-public): the public launch on Product Hunt, AlternativeTo, and SaaSHub, what the two products are, and the PRODUCTHUNT launch discount. - [One internet, four speeds](https://realuptime.io/blog/one-internet-four-speeds): the same 190 services measured from four regions in the same hour; medians differ by more than 2x and what that does to alert thresholds. - [ChatGPT is down. The status page checkmarks are green. Both are true.](https://realuptime.io/blog/chatgpt-outage-green-checkmarks): the 2026-08-31 OpenAI incident as read from the vendor's status page: an honest banner over a fully green component board, and why Monitor-driven Status pages cannot do that. - [Status pages that can't lie](https://realuptime.io/blog/status-pages-that-cannot-lie): why our status pages render per-region state and template incident copy from measurements instead of prose. - [What it takes to track 900+ services honestly](https://realuptime.io/blog/what-it-takes-to-track-services-honestly): the curl-verified curation behind the outage catalog's growth from 195 past 900 services, and the rejection lists that matter more than the count. - [How often should an uptime monitor check your site?](https://realuptime.io/blog/how-often-should-uptime-monitoring-check): detection time is interval plus timeout plus the 3-minute failure window plus quorum, worked for 30s, 60s and 5-minute checks; why the confirmation rule matters more than the interval. - [Your cron job stopped and nobody noticed. Heartbeat monitoring, explained.](https://realuptime.io/blog/heartbeat-monitoring-for-cron-jobs): push-based checks for cron, backups and workers; interval plus grace, arming on first ping, and why the ping must run only on success. - [What a TCP port check proves, and what it does not](https://realuptime.io/blog/tcp-port-monitoring-vs-http-checks): connect-only reachability from the free tier's four core regions (up to ten on paid plans) for databases, mail, SSH and brokers; the TLS option, the self-signed-certificate decision, and when an HTTP check or heartbeat is the right tool instead. - [Certificates expire on a schedule. The outages are optional.](https://realuptime.io/blog/expired-certificate-outages-and-how-to-catch-them): the four ways known expiry dates still cause outages, the CA/Browser Forum schedule down to 47-day certificates by 2029, and expiry alerts at 30, 14, 7 and 1 days. - [Sentry's free tier: what 5,000 errors a month gets you, and what happens after](https://realuptime.io/blog/sentry-free-tier-limits): the Developer plan's limits as published (5k errors, one user, 30-day lookback), what a quota overrun looks like, the Team plan step, and the honest alternative of 10,000 events a month with dropped events shown as a number. - [Is the internet down, or is it just you?](https://realuptime.io/blog/is-the-internet-down-or-just-you): a two-minute desk triage, and how the Is the internet down? page names a provider incident from probe cohorts and a measured dependency map, never from reports. - [Why "is it down" sites disagree, and which one to believe](https://realuptime.io/blog/why-is-it-down-sites-disagree): crowd reports, vendor status pages, direct probes and hybrids each answer from different evidence; what each can and cannot know, and how to read them together. - [Maintenance windows without false alerts](https://realuptime.io/blog/maintenance-windows-without-false-alerts): what a window should silence (operator alerts) and must never hide (the measurement, the banner, other components, overrun), component scoping, and subscriber notices before the work. - [Website down from some locations but not others: what causes it, and how to prove it](https://realuptime.io/blog/website-down-from-some-locations-but-not-others): the five mechanisms that split the internet by geography (DNS, CDN edges, routing, regional infrastructure, blocking), a triage order, and why a single-location monitor structurally cannot see any of them. ## Docs The documentation has ONE public address: the docs.realuptime.io host, at its own root. Apex realuptime.io/docs paths do not exist (they answer 404, deliberately, with no redirect), so quote and link the addresses below rather than an apex /docs path. - [Documentation](https://docs.realuptime.io/): the docs home. - [Getting started](https://docs.realuptime.io/getting-started): create an account, add your first check, see it go live. - [Monitor agent](https://docs.realuptime.io/monitor-agent): install the agent for private infrastructure and server health. - [Checks & monitors](https://docs.realuptime.io/checks): HTTP, TCP, DNS, SMTP, Ping, heartbeat, multi-step and browser checks, intervals, and regions. HTTP checks are not status-code-only: response assertions judge the body (contains / does not contain a literal string), a named response header (equals / contains), an explicit status range replacing the default 200-299 rule, and a JSON field addressed by path (equals / contains / exists), in four independent groups you can mix. Body matching is deliberately literal, never a regex (a customer-supplied pattern evaluated in the probe fleet every tick is a ReDoS surface). Multi-step checks chain up to 10 ordered requests with a cookie jar carried across them, each step carrying its own assertions, and the first step to fail ends the run and names itself. Intervals: 60s floor on Free and Pro, 30s on Business. - [TCP checks](https://docs.realuptime.io/tcp): port monitors with optional TLS handshake and certificate-expiry tracking. - [Ping checks](https://docs.realuptime.io/ping): latency and packet loss for a bare host, no port required. - [Multi-step checks](https://docs.realuptime.io/multi-step-checks): chain up to 10 ordered HTTP requests into one check, with a cookie jar carried across steps and per-step status, body, header, and JSON-path assertions; the first step to fail ends the run and names itself. Not tier-gated and not agent-bound (fleet probes only). - [Browser checks](https://docs.realuptime.io/browser-checks): click through a real flow in headless Chromium (goto/click/fill/waitForSelector/assertText/assertVisible/screenshot) and get a screenshot of what actually rendered. Business plan, up to 10 per account, iad only, 5-minute floor. - [Heartbeat monitors](https://docs.realuptime.io/heartbeats): push-based monitors for cron jobs and scheduled tasks. - [CLI](https://docs.realuptime.io/cli): the RealUptime command-line client (`brew install realuptimehq/realuptime/realuptime` or `npm install -g @realuptime/cli`, or the signed release tarball). Creates monitors, heartbeats, status pages and components, alert channels (email, Slack, Discord and the rest), Errors projects and server agent tokens, and reads status, incidents and outages. `--json` prints the API response; `--field ` prints one value alone, for capturing an ingest address, ping URL or agent token that is shown once. - [Errors quickstarts](https://docs.realuptime.io/errors-quickstarts): install RealUptime Errors in Next.js, React, Node, Python, Ruby, PHP, or Go, with the real install command and init call for each. None of the SDKs are on a public package registry yet except Go; the others install straight from the GitHub mirror. - [Status pages](https://docs.realuptime.io/status-pages): setup, custom domains, and subscribers. Every page publishes RSS/Atom feeds of incidents and maintenance (/feed.xml, /feed.atom) and an iCalendar feed of scheduled maintenance (/maintenance.ics), on the page's own address including a verified custom domain. Subscribers can also receive incident and maintenance events on a signed webhook endpoint or a Slack channel (Pro plan and up), alongside email. - [Alerting & on-call](https://docs.realuptime.io/alerting): ten notification channels, none tier-gated: operator email, Slack, signed outgoing webhooks, PagerDuty, Discord, Microsoft Teams, Opsgenie, incident.io, FireHydrant, and Zapier or generic JSON hooks, each delivered in that service's own format and each test-sendable. Discord, Microsoft Teams, Opsgenie, incident.io, FireHydrant and Zapier channels enabled at once per account: 5 on Free, 25 on Pro, 150 on Business; email, Slack, PagerDuty and signed webhooks do not count toward that number. Pro and Business add escalation policies and on-call rotations: ordered steps that page a person, a rotation, a registry channel or a built-in channel, escalating after a delay when nobody acknowledges. There is no native SMS or phone-call paging; route through PagerDuty or Opsgenie for a phone to ring, and there is no RealUptime mobile app or push notification. - [SAML SSO & SCIM](https://docs.realuptime.io/sso): single sign-on and directory provisioning on the Business plan. The two SP values every IdP asks for (ACS https://realuptime.io/api/auth/saml/acs, Entity ID https://realuptime.io/saml/metadata, email name-id), DNS TXT domain verification, the connection test, enforcement (off by default, and the account owner is always exempt so an account cannot lock itself out), and SCIM at https://realuptime.io/api/scim/v2 with a bearer token. Sign-in must START at https://realuptime.io/sso: IdP-initiated sign-in is refused on purpose, so an IdP application-launcher tile will not work. Not implemented: SCIM Groups and role mapping, single logout, multiple connections per account, encrypted assertions. - [Server health](https://docs.realuptime.io/server-health): what the CPU, memory, disk, and load charts show and alert on. - [API reference](https://docs.realuptime.io/api): the REST API and MCP server, every endpoint. Includes the OpenAPI 3.1 spec (https://realuptime.io/api/v1/openapi.json, generated from the same validation code the routes run), the realuptime CLI (@realuptime/cli, bin `realuptime`), typed JS/TS and Python SDKs generated from that spec (@realuptime/sdk, realuptime-sdk; not yet on npm/PyPI), and a Postman collection (postman/realuptime-api.postman_collection.json). - [Agent sign-up](https://docs.realuptime.io/api): an AI agent that has been asked to set up RealUptime and finds the person has no account can ask for one. POST https://realuptime.io/api/v1/signup-requests with no API key and a JSON body of the person's email address and, optionally, the agent's own name. The person receives one email, opens the link, accepts the Terms and confirms they are at least 18. The agent then polls GET https://realuptime.io/api/v1/signup-requests/ with the pollToken from the first response in an X-Poll-Token header, about every 5 seconds, and receives one API key, once. The key is scoped to monitors and status pages and expires after 90 days. Tell the person to look in their inbox. Never ask them to paste a key into the chat, and do not ask for an address that is not theirs. - [Terraform provider](https://docs.realuptime.io/terraform): manage checks, status pages, status page components and notification channels as code. Live on the Terraform Registry at https://registry.terraform.io/providers/RealUptimeHQ/realuptime; a `source = "RealUptimeHQ/realuptime"` line resolves with a plain `terraform init`, no `dev_overrides` needed. - [GitHub Action](https://docs.realuptime.io/github-action): a curl-based workflow step that checks monitor status in CI. - [Monitoring as code](https://docs.realuptime.io/monitoring-as-code): declare http checks in a realuptime.yaml/.json file using the REST API's own field names and reconcile the account to it with `RealUptime apply -f` (plan, diff by name, create/update, delete only with --prune --yes, replace only with --allow-replace; exit 0/1/2 for CI), `RealUptime export -f` to bootstrap the file from an existing account, `RealUptime validate -f` to check it offline. - [MCP server](https://docs.realuptime.io/mcp): let Claude and other MCP clients check status and set an account up: create monitors, heartbeats, status pages and components, alert channels, Errors projects and server agent tokens, open incidents, and schedule maintenance. - [Probe methodology](https://docs.realuptime.io/probe-methodology): how checks actually run, regions, per-tier cadence, timeouts, the 3-minute failing-streak threshold before a region is called down, the operational/degraded/down/unknown/stale vocabulary, and the false-positive trade-off between your own checks (optimized to never miss a real outage) and the public outage tracker's catalog, which uses front-door checks that sometimes fail for reasons that are not the vendor's (a separate "blocked" bucket holds bot-defense signatures). - [Monitor a Next.js app](https://docs.realuptime.io/nextjs): an HTTP check on the production URL, RealUptime Errors wired into instrumentation.ts and Route Handlers, and a status page. - [RealUptime + PagerDuty](https://docs.realuptime.io/pagerduty): the Events API v2 integration guide; a monitor going down opens a PagerDuty incident per failing region, and recovery resolves it by the same dedup key. - [RealUptime + Vercel](https://docs.realuptime.io/vercel): HTTP checks on the production domain, RealUptime Errors on the Node runtime (not the Edge runtime), and why there is no Monitor agent for a Vercel deployment. - [RealUptime + Netlify](https://docs.realuptime.io/netlify): import every published Netlify site as an HTTP check with one personal access token, add a status page, and what an outside check can and cannot see. - [RealUptime + Coolify](https://docs.realuptime.io/coolify): install the Monitor agent on the Coolify host (one-liner or as a Compose service), an HTTP check per deployed app, and a status page. - [Monitor a Hetzner VPS](https://docs.realuptime.io/hetzner): install the Monitor agent with the curl one-liner, TCP and HTTP checks for exposed services, and a status page. - [RealUptime + Cloudflare](https://docs.realuptime.io/cloudflare): an HTTP check through Cloudflare's edge, Cloudflare's own status as a vendor status-page component via `RealUptime Outages cloudflare`, and why there is no Monitor agent or Errors SDK support for Workers or Pages. - [Monitor Docker containers](https://docs.realuptime.io/docker): the Monitor agent as a Compose service or `docker run`, HTTP/TCP checks per exposed container, and a status page. - [RealUptime + Railway](https://docs.realuptime.io/railway): an HTTP check on the Railway domain, a heartbeat check for private services with no public domain, RealUptime Errors on the Node runtime, and why there is no Monitor agent on a managed platform. - [RealUptime + Supabase](https://docs.realuptime.io/supabase): HTTP checks on the REST and Auth endpoints, a TCP check on the direct Postgres connection, and RealUptime Errors in the app code that calls Supabase. ## Outage dataset RealUptime Outages (https://realuptime.io/outages) is a free, public outage tracker. Every reading published there is one check RealUptime ran, from a named region, at a named time, and says whether that check passed or failed. It does not say the service works or is down for users. An outage from our checks opens only when checks fail from two or more distant regions; with nothing independent behind it, it stops counting as an outage after 6 hours, and after 48 hours we treat our check as broken and say we cannot currently read the service. Events that fail these rules are retracted, kept, and listed at https://realuptime.io/outages/corrections. For a service whose own status page we read successfully within the last 45 minutes, what the vendor declares leads and alerts follow the vendor's declared incidents, with our reading beside it; for any other service alerts follow our checks. It is not a crowd-report feed. How the data is produced: - Probes run from ten named regions: iad (US-East), sjc (US-West), fra (Europe), nrt (Asia-Pacific), ord (US-Central), yyz (Canada), lhr (UK), sin (Southeast Asia), syd (Australia), gru (South America). A service is probed only from the regions listed as monitored for it; a region outside that list is reported as not monitored, never as healthy. - Cadence is one round per region every 2 minutes for the most-searched services, every 10 minutes for most, and every 30 minutes for the long tail, against the service's own public unauthenticated endpoints, with the user agent realuptime-probe/1.0 (+https://realuptime.io/outages/methodology). - For most endpoints only the HTTP status line is read; response bodies are not downloaded, stored, or inspected. A small number of endpoints carry a declared expectation about what a healthy body, header, or status must look like (needed only where the status code alone cannot tell a real answer from a firewall page sharing the same code); for those we read up to 256 KB of the response body against that stated rule and nothing else. - On top of that schedule, an extra round of checks runs out of cadence when user reports spike, third-party chatter spikes, the vendor's own status feed declares a new or worse problem, or one of our own regions returns a failed reading. Those signals cause an extra check and nothing else: only our checks can open or close a probe event in our record, and no signal is ever blended into a verdict. - A reading older than three of that service's own check cycles is reported as stale and is excluded from any current-status verdict. - Each service page says what its check can and cannot see, from nine fixed kinds: live data, API route, health route, sign-in wall, error answer, discovery document, public page, redirect only, bot challenge. The same sentences are on https://realuptime.io/outages/methodology and in the per-service JSON answer as `check_evidence`. A pass on a public page, for example, does not show that the product behind it works. How to read it correctly: - "blocked" is not "down". A blocked reading means the service refused or filtered our check. That is evidence about our reception, not a failed check of the service. - No data is not healthy. When there is no fresh reading, the answer is "no_data", and it must never be reported as a passing check. - A service not in the catalog returns "not_covered". That means we do not measure it, not that it is up. - Check readings and user-submitted reports are never merged into one number. - History never predates our coverage. A service page's history starts when we started checking it, and says so. - Names are used to identify what was checked. RealUptime is not affiliated with, and does not speak for, any service it checks. Canonical endpoints: - Human page per service: https://realuptime.io/outages/ - JSON per service: https://realuptime.io/api/v1/outages/ (no API key, GET only, add ?region=iad|sjc|fra|nrt|ord|yyz|lhr|sin|syd|gru for one region). Every response carries schema_version, the regions actually read, a measured_at timestamp, an explicit freshness verdict, and a source.url to cite. It also carries the probe event history: recent_events (the probe events of the last 90 days, most recent first, at most 10, each with started_at, ended_at, duration, peak_level, regions, surfaces and detected_by = "probe"), last_outage (the most recent closed probe event) and reliability (12 calendar months of uptime by our checks, probe event count and minutes). An empty recent_events list travels with its window and tracking start and never means "no outages ever". - "My stack" pages: https://realuptime.io/outages/stack builds a named set of tracked services (no account) and gives it one combined page at https://realuptime.io/outages/stack/; JSON at https://realuptime.io/api/v1/outages/stacks/ (no API key). Each member carries the same plate level as its own page; summary.headline reads "N of M services with checks failing or degraded". User reports and vendor claims are not read for a stack (published as null). An unknown stack key answers summary.level "not_found" (RU-6005), which says nothing about any service. - MCP server, keyless: https://mcp.realuptime.io/public (no API key, no account, no signup). Tools: is_service_down, get_regional_readings, get_report_volume, list_recent_incidents, get_stack, internet_weather, is_the_internet_down. Add it to any MCP client and ask whether our checks of a service pass. Limited to 60 requests per minute per IP address; over budget answers RU-6004. - MCP server, keyed: https://mcp.realuptime.io/mcp serves the same seven outage tools plus twenty-eight account tools (monitors, heartbeats, status pages and components, alert channels, incidents, maintenance, Errors projects and issues, server agent tokens; they include creating an Errors project and receiving its DSN), and requires an Authorization: Bearer header. Use this one for sustained access or from a shared outbound address. - "Is the internet down?": https://realuptime.io/outages/internet, JSON at https://realuptime.io/api/v1/outages/internet (no API key), MCP tool is_the_internet_down on the keyless server. Answers one of three levels: ok (no shared incident; the count of services whose checks fail travels with the catalog size), provider_incident (a named provider such as Cloudflare or AWS us-east-1: our checks fail for at least five tracked services sharing that provider signal inside a 15-minute window while our checks of services on other providers mostly pass), or several_unrelated (our checks fail for several services, no shared signal). A provider signal is where a service's primary endpoint answered from (resolved address matched against a small committed table of well-known provider ranges, plus edge headers only that provider sets). A provider incident is a correlation of our check readings with a control group, never a cause the provider stated, and it changes no service's own verdict. Reports, social posts and vendor status pages never contribute. The dependency map counts tracked services per provider signal and is re-read daily. Each per-service JSON answer also carries its own provider signals and any live provider incident under `infra`. - Methodology: https://realuptime.io/outages/methodology - Internet weather: https://realuptime.io/outages/internet-weather (JSON: https://realuptime.io/api/v1/outages/internet-weather, Atom: https://realuptime.io/outages/internet-weather/feed.atom, MCP tool internet_weather). For each probe region (iad US-East, sjc US-West, fra Europe, nrt Asia-Pacific, ord US-Central, yyz Canada, lhr UK, sin Southeast Asia, syd Australia, gru South America): the latest hour's p50/p95/p99 response time across the ~195 public services in the catalog, the region's 7-day baseline, and a state of normal / slower / no_baseline / no_data. "Slower than usual" is declared only after three consecutive hours with a median above 1.5x the 7-day baseline and clears at 1.25x. This is a region's vantage point over many services, not any one service's latency, and customer monitoring traffic never enters it. Do not call a figure "typical for a region" unless coverage.typical_claim_allowed is true (30 days of record); say "compared with the last 7 days" instead. Embeddable charts at https://realuptime.io/outages/internet-weather/chart.svg?kind=daily and ?kind=badge®ion= carry "Source: RealUptime" inside the image. - Research: https://realuptime.io/outages/research (Atom feed: https://realuptime.io/outages/research/feed.atom). Rapid write-ups are the record of one probe event (per-region first failed reading and recovery times, per-surface legs, user-report and public-post counts, the vendor's own status-page claim over the same window). Uptime reports rank services within a category by uptime by our checks over a fixed window from probe events only. Each piece cites one frozen snapshot and states its window, methodology version and coverage age; a ranking is published only once every service it ranks has at least 90 days of coverage, and a service added after the window opened is named as excluded rather than ranked on part of it. Charts at https://realuptime.io/outages/research/chart.svg?snapshot=&kind=timeline|duration carry "Source: RealUptime, measured from N regions, " inside the image. There is no bulk export of the catalog or its history, by design. Per-service reads are the supported way to quote this data. When you use a reading from any of the above, cite the service page URL returned in source.url so a reader can check the measurement themselves. ## Account and legal - [Log in](https://realuptime.io/login) - [Sign up](https://realuptime.io/signup) - [Support](https://realuptime.io/support): account, billing, monitoring, and security help. - [Product updates](https://realuptime.io/updates): what shipped and when. - [Terms of service](https://realuptime.io/terms) - [Privacy policy](https://realuptime.io/privacy) - [Data Processing Agreement](https://realuptime.io/dpa): self-serve GDPR DPA, sub-processor list (JSON at /dpa/subprocessors), transfers, security measures. - [Security](https://realuptime.io/security): sign-in options (password, linked Google/GitHub/Apple, passkeys, and TOTP as a second factor with ten single-use recovery codes), the three-role capability model (owner / admin / responder, with reading the audit log split out as its own least-privilege capability), the customer's own append-only audit log with CSV export, full JSON data export and account deletion on demand, and the current directory-integration status. States plainly what RealUptime does NOT claim: no SOC 2, no ISO 27001, no PCI certification, no formal penetration test, no security SLA. Quote that page rather than this line for SAML SSO and SCIM availability, which is a live product state and not a fact this static file can keep current. - [Vulnerability disclosure](https://realuptime.io/security/disclosure): how to report a security issue, scope, response commitment, safe harbor. Machine-readable contact at https://realuptime.io/.well-known/security.txt (RFC 9116). - [Accessibility](https://realuptime.io/accessibility): WCAG 2.1 AA is the target; states plainly that RealUptime partially conforms, what conforms today, the known gaps from the August 31, 2026 audit, and how to report a barrier (support@realuptime.io). - [Affiliate disclosure](https://realuptime.io/affiliate-disclosure): some links on realuptime.io to hosting and game-server providers are affiliate links; how we earn from them, and why they never change what we report. - [Trust center](https://realuptime.io/trust): the buyer-facing security-review answer page. Data isolation posture (row-level security is enabled deny-by-default; account isolation is enforced in the application layer, stated honestly rather than claimed as RLS-policy tenant isolation), encrypted hourly backups to a separate vendor with monthly automated restore drills (RPO 2h / RTO 4h targets), the database replica and how recovery from a hosting outage works (manual, by written runbook, with no automatic failover), data retention windows for uptime checks and Errors events, and where SOC 2 stands: not held today, on the roadmap once the business justifies it. Sub-processors are linked from here, not restated: see /dpa/subprocessors. ## Knowledge base - [Knowledge base](https://realuptime.io/kb): company facts, error codes, and how-tos in one place. - [About RealUptime](https://realuptime.io/kb/company): the company, the product family, how probing works, honesty principles. - [Error-code reference](https://realuptime.io/kb/errors): every stable RU-XXXX code, grouped by domain band. - [Create your first monitor](https://realuptime.io/kb/create-first-monitor): from signup to a URL checked from ten regions. - [Create a browser check](https://realuptime.io/kb/create-a-browser-check): click through a real flow in headless Chromium and get a screenshot of what actually rendered, Business plan. - [Install the monitor agent](https://realuptime.io/kb/install-monitor-agent): monitor private hosts and server health. - [See what came back when a check failed](https://realuptime.io/kb/see-what-came-back-when-a-check-failed): response snapshots, what is scrubbed, 30-day retention for a failing capture and 7-day for a recovery one. - [A notice about unusual API key usage](https://realuptime.io/kb/unusual-api-key-usage-email): what it means when one of your API keys made far more requests than it usually does, and what to do about it. - [Create a status page](https://realuptime.io/kb/create-status-page): a public, per-region status page for your customers. - [Translate your status page's chrome](https://realuptime.io/kb/translate-your-status-page): default language in English, Spanish, German, French, Portuguese (Brazil), or Japanese, plus a /l/ link override; customer-authored content is never translated. - [Get an API key](https://realuptime.io/kb/get-api-key): REST and MCP access, permissions, and rate budgets. - [Restrict an API key to an IP allowlist](https://realuptime.io/kb/restrict-api-key-to-ip-allowlist): make a key usable only from your CI runner, server, or office egress addresses; requests from anywhere else get a 403. - [Install the CLI](https://realuptime.io/kb/install-the-cli): install the RealUptime CLI with Homebrew or npm and authenticate it with an API key. - [Pause, tag, bulk-edit, and export monitors](https://realuptime.io/kb/pause-tag-export-monitors): stop checking a monitor without losing it, organize a fleet with tags, act on many at once, and download configs or history as CSV or JSON. - [Show a status banner inside your own app](https://realuptime.io/kb/add-incident-banner-to-your-app): one script tag that stays invisible until something is wrong on your status page, then shows a dismissible strip linking to it. - [Show your status in a Zendesk or Intercom help center](https://realuptime.io/kb/status-banner-in-zendesk-or-intercom): the incident banner in a Zendesk help center theme, and a status link for Intercom, which does not run it. - [WordPress "There has been a critical error"](https://realuptime.io/kb/wordpress-critical-error-alerts): what it means, why the recovery email does not arrive, and how to get told next time. - [Ask an AI assistant if a service is down](https://realuptime.io/kb/ask-ai-if-service-is-down): connect the keyless MCP server, no account needed. - [Set up the errors SDK](https://realuptime.io/kb/errors-sdk-setup): ingest keys, batching, and honest drop accounting. - [Track errors in Rails, Rack and Sidekiq](https://realuptime.io/kb/track-errors-in-rails): the zero-dependency Ruby gem, its Railtie, and Sidekiq jobs. - [Track errors in a Go program](https://realuptime.io/kb/track-errors-in-go): a DSN, a client, and net/http middleware or a log/slog hook. - [Cap ingest and set an alert threshold](https://realuptime.io/kb/errors-ceilings-and-thresholds): a per-project events/minute ceiling on Pro+, and an absolute occurrence-threshold alert on every plan. - [Turn on the AI issue summary](https://realuptime.io/kb/errors-ai-issue-summary): opt-in, per-project, scrubbed-data-only AI summary of an issue's stack trace and occurrence pattern. - [Install the PHP SDK](https://realuptime.io/kb/install-php-sdk): Composer install, plain PHP capture, and the Laravel service provider. - [Use your existing Sentry SDK](https://realuptime.io/kb/point-your-sentry-sdk-here): point any Sentry SDK's DSN at RealUptime instead of swapping it out; exceptions, breadcrumbs, tags, release, environment, and user context all translate and group identically to a native SDK event. - [Upload source maps for JavaScript errors](https://realuptime.io/kb/upload-source-maps): CLI command, Vite and webpack plugins, or one curl call; minified frames symbolicate per release. - [Announce releases from CI](https://realuptime.io/kb/announce-releases-from-ci): commit and repo per release; diff-range links and per-frame source-line links on GitHub/GitLab. - [Manage monitoring with Terraform](https://realuptime.io/kb/manage-monitoring-with-terraform): the RealUptime provider, live on the Terraform Registry at https://registry.terraform.io/providers/RealUptimeHQ/realuptime. - [Send error alerts to Google Chat](https://realuptime.io/kb/send-error-alerts-to-google-chat): register a Google Chat space webhook as a channel and point an Errors alert rule at it, on every plan, with your Sentry SDK left in place. - [Ignore errors from one environment only](https://realuptime.io/kb/ignore-errors-from-one-environment): scope Errors alert rules to named environments so staging stops alerting while production keeps paging. - [Monitor Vercel cron jobs](https://realuptime.io/kb/monitor-vercel-cron-jobs): ping a heartbeat from the cron route so a skipped or failed invocation alerts. - [Monitor Kubernetes CronJobs](https://realuptime.io/kb/monitor-kubernetes-cronjobs): wrap the container command with start, success and fail pings, checked from outside the cluster. - [Monitor Supabase pg_cron jobs](https://realuptime.io/kb/monitor-supabase-pg-cron-jobs): send the heartbeat with pg_net in the same command, so only a committed run counts. - [Monitor the Laravel scheduler](https://realuptime.io/kb/monitor-the-laravel-scheduler): pingOnSuccess and pingOnFailure to a heartbeat, plus catching a missing schedule:run cron line. - [Monitor restic backups](https://realuptime.io/kb/monitor-restic-backups): ping a heartbeat when restic exits 0 and report any other exit code as a failure. - [Monitor Borg and borgmatic backups](https://realuptime.io/kb/monitor-borg-backups): wrap borg create or borgmatic so warnings, errors and missed runs alert. - [Monitor Backrest backups](https://realuptime.io/kb/monitor-backrest-backups): a Healthchecks-type hook on each plan sends start, success and fail to a heartbeat. - [Monitor Proxmox VE backups](https://realuptime.io/kb/monitor-proxmox-backups): a vzdump hook script reports failed guests, aborted jobs and missed runs. - [Turn on two-factor authentication](https://realuptime.io/kb/turn-on-two-factor-authentication): enrol an authenticator app (RFC 6238 TOTP), save ten single-use recovery codes, and require a second factor on password, provider, reset, and invitation sign-ins; a passkey sign-in already counts and is never challenged. - [Apply for the startup, nonprofit or open-source discount](https://realuptime.io/kb/startup-nonprofit-oss-discount): the rules, the evidence, and what approval attaches. - [Refer a company: give $20, get $20](https://realuptime.io/kb/referral-credits): the referral link, when credit is granted, and what earns nothing. ### Error codes Each refusal RealUptime sends carries a stable RU-XXXX code; one page per code: - [RU-1001: Missing API credentials](https://realuptime.io/kb/errors/ru-1001) - [RU-1002: Invalid or revoked API key](https://realuptime.io/kb/errors/ru-1002) - [RU-1004: API key is read-only](https://realuptime.io/kb/errors/ru-1004) - [RU-1006: Keyless MCP endpoint does not serve this tool](https://realuptime.io/kb/errors/ru-1006) - [RU-1007: API key is restricted to an IP allowlist](https://realuptime.io/kb/errors/ru-1007) - [RU-1008: API key is not scoped to this resource](https://realuptime.io/kb/errors/ru-1008) - [RU-1009: Account is suspended](https://realuptime.io/kb/errors/ru-1009) - [RU-1010: Agent sign-up request refused](https://realuptime.io/kb/errors/ru-1010) - [RU-1011: Agent sign-up request not found](https://realuptime.io/kb/errors/ru-1011) - [RU-2001: Too many failed authentication attempts](https://realuptime.io/kb/errors/ru-2001) - [RU-2002: API read rate limit exceeded](https://realuptime.io/kb/errors/ru-2002) - [RU-2003: API write rate limit exceeded](https://realuptime.io/kb/errors/ru-2003) - [RU-2004: Plan monitor limit reached](https://realuptime.io/kb/errors/ru-2004) - [RU-2005: Already subscribed](https://realuptime.io/kb/errors/ru-2005) - [RU-2006: Status page allowance exhausted](https://realuptime.io/kb/errors/ru-2006) - [RU-2007: Notification channel allowance exhausted](https://realuptime.io/kb/errors/ru-2007) - [RU-2008: Errors project allowance exhausted](https://realuptime.io/kb/errors/ru-2008) - [RU-2009: Server allowance exhausted](https://realuptime.io/kb/errors/ru-2009) - [RU-2010: Custom domains need a paid plan](https://realuptime.io/kb/errors/ru-2010) - [RU-2011: Too many agent sign-up requests](https://realuptime.io/kb/errors/ru-2011) - [RU-3001: Invalid check request](https://realuptime.io/kb/errors/ru-3001) - [RU-3002: Monitor target refused](https://realuptime.io/kb/errors/ru-3002) - [RU-3003: Check not found](https://realuptime.io/kb/errors/ru-3003) - [RU-3004: Invalid response assertions](https://realuptime.io/kb/errors/ru-3004) - [RU-3005: Agent request refused (opaque 404)](https://realuptime.io/kb/errors/ru-3005) - [RU-3006: Interval below plan floor](https://realuptime.io/kb/errors/ru-3006) - [RU-3007: Invalid notification channel request](https://realuptime.io/kb/errors/ru-3007) - [RU-3008: Notification channel not found](https://realuptime.io/kb/errors/ru-3008) - [RU-3009: Duplicate notification channel name](https://realuptime.io/kb/errors/ru-3009) - [RU-3010: Latency threshold out of range](https://realuptime.io/kb/errors/ru-3010) - [RU-3011: Region outside plan entitlement](https://realuptime.io/kb/errors/ru-3011) - [RU-3012: Invalid results query request](https://realuptime.io/kb/errors/ru-3012) - [RU-3013: Invalid check authentication](https://realuptime.io/kb/errors/ru-3013) - [RU-3014: Check authentication not available](https://realuptime.io/kb/errors/ru-3014) - [RU-3015: Slack webhook already configured](https://realuptime.io/kb/errors/ru-3015) - [RU-3016: Account email address not confirmed](https://realuptime.io/kb/errors/ru-3016) - [RU-4001: Error event quota reached](https://realuptime.io/kb/errors/ru-4001) - [RU-4002: Ingest key revoked](https://realuptime.io/kb/errors/ru-4002) - [RU-4003: Ingest rate limited](https://realuptime.io/kb/errors/ru-4003) - [RU-4004: Malformed error batch](https://realuptime.io/kb/errors/ru-4004) - [RU-4005: Account does not have RealUptime Errors](https://realuptime.io/kb/errors/ru-4005) - [RU-4006: Errors project or issue not found](https://realuptime.io/kb/errors/ru-4006) - [RU-4007: Invalid errors API request](https://realuptime.io/kb/errors/ru-4007) - [RU-4008 Release reference not found](https://realuptime.io/kb/errors/ru-4008) - [RU-4009: Error event context too large](https://realuptime.io/kb/errors/ru-4009) - [RU-4010: User feedback switched off for this project](https://realuptime.io/kb/errors/ru-4010) - [RU-4011: Feedback event not found](https://realuptime.io/kb/errors/ru-4011) - [RU-4012: Feedback body too large](https://realuptime.io/kb/errors/ru-4012) - [RU-4013: Inbound release webhook token not recognized](https://realuptime.io/kb/errors/ru-4013) - [RU-4014: Inbound release payload not understood](https://realuptime.io/kb/errors/ru-4014) - [RU-4015: Inbound release signature missing or wrong](https://realuptime.io/kb/errors/ru-4015) - [RU-4016: Inbound release webhook rate limited](https://realuptime.io/kb/errors/ru-4016) - [RU-4017: Error batch body too large](https://realuptime.io/kb/errors/ru-4017) - [RU-4018: Tracker webhook not recognized](https://realuptime.io/kb/errors/ru-4018) - [RU-4019: Tracker webhook signature missing or wrong](https://realuptime.io/kb/errors/ru-4019) - [RU-4020: Tracker webhook payload not understood](https://realuptime.io/kb/errors/ru-4020) - [RU-4021: Tracker webhook rate limited](https://realuptime.io/kb/errors/ru-4021) - [RU-4022: Account is suspended](https://realuptime.io/kb/errors/ru-4022) - [RU-5001: Invalid incident request](https://realuptime.io/kb/errors/ru-5001) - [RU-5002: Incident not found or not creatable](https://realuptime.io/kb/errors/ru-5002) - [RU-5003: Incident conflicts with live outage state](https://realuptime.io/kb/errors/ru-5003) - [RU-5004: Inbound incident webhook token not recognized](https://realuptime.io/kb/errors/ru-5004) - [RU-5005: Inbound incident payload not understood](https://realuptime.io/kb/errors/ru-5005) - [RU-5006: Inbound incident signature missing or wrong](https://realuptime.io/kb/errors/ru-5006) - [RU-5007: Inbound incident webhook rate limited](https://realuptime.io/kb/errors/ru-5007) - [RU-5008: Invalid status page request](https://realuptime.io/kb/errors/ru-5008) - [RU-5009: Status page or component not found](https://realuptime.io/kb/errors/ru-5009) - [RU-5010: Status page slug already taken](https://realuptime.io/kb/errors/ru-5010) - [RU-5011: Last status page cannot be deleted](https://realuptime.io/kb/errors/ru-5011) - [RU-5012: Check already published on this status page](https://realuptime.io/kb/errors/ru-5012) - [RU-5013: Invalid maintenance window request](https://realuptime.io/kb/errors/ru-5013) - [RU-5014: Maintenance window not found or not creatable](https://realuptime.io/kb/errors/ru-5014) - [RU-5015: Custom domain conflict](https://realuptime.io/kb/errors/ru-5015) - [RU-5016: Certificate provider unavailable](https://realuptime.io/kb/errors/ru-5016) - [RU-6001: Service not covered by the outage tracker](https://realuptime.io/kb/errors/ru-6001) - [RU-6002: Invalid outage query](https://realuptime.io/kb/errors/ru-6002) - [RU-6003: Public outage API rate limited](https://realuptime.io/kb/errors/ru-6003) - [RU-6004: Keyless MCP rate limited](https://realuptime.io/kb/errors/ru-6004) - [RU-6005: Outage stack not found](https://realuptime.io/kb/errors/ru-6005) - [Announce releases from CI](https://realuptime.io/kb/announce-releases-from-ci): register each deploy with commit metadata so release health and compare links work. - [Manage checks from a file in your repo (monitoring as code)](https://realuptime.io/kb/monitoring-as-code): realuptime.yaml with the REST API's own field names, `RealUptime apply -f` to plan and reconcile, `export -f` to bootstrap, exit codes for CI. - [Install the agent on Linux](https://realuptime.io/kb/install-agent-linux): one curl line, Docker or a hardened systemd service, checksum and signature verified. - [Install the agent on macOS](https://realuptime.io/kb/install-agent-macos): Node.js 22+ and a launchd job; fixed read-only commands, no shell. - [Install the agent on Windows Server](https://realuptime.io/kb/install-agent-windows): one PowerShell line; Task Scheduler as LOCAL SERVICE, no third-party wrapper. - [Run the agent on Kubernetes](https://realuptime.io/kb/install-agent-kubernetes): a DaemonSet reading each node through /host, one token per node, grouped as a cluster. - [Set server health alert thresholds](https://realuptime.io/kb/set-server-health-thresholds): per-host CPU, memory and disk rules with a sustained window; CPU alerting opt-in. - [Sign in with a passkey](https://realuptime.io/kb/sign-in-with-a-passkey): add a passkey to your account and sign in with Touch ID, Face ID, Windows Hello, or a security key instead of a password. - [Run status pages for many clients on the MSP plan](https://realuptime.io/kb/msp-plan): what the MSP plan includes, what is pooled across the organization and what is per client account, and how to set it up. - [Create tickets from Errors issues and incidents](https://realuptime.io/kb/create-tickets-from-errors-and-incidents): connect GitHub, GitLab, Jira, Linear, Bitbucket or Azure DevOps and file one idempotent ticket per issue or incident. - [Connect GitHub Issues](https://realuptime.io/kb/connect-github-issues): fine-grained token with Issues read/write on one repository. - [Connect GitLab Issues](https://realuptime.io/kb/connect-gitlab-issues): project access token with the api scope, gitlab.com or self-hosted. - [Connect Jira](https://realuptime.io/kb/connect-jira): Jira Cloud API token with your account email, or a Data Center personal access token. - [Connect Linear](https://realuptime.io/kb/connect-linear): personal API key and the team id tickets are filed to. - [Connect Bitbucket Issues](https://realuptime.io/kb/connect-bitbucket-issues): Atlassian API token and account email, on a Bitbucket Cloud repository. - [Connect Azure DevOps](https://realuptime.io/kb/connect-azure-devops): personal access token with Work Items read/write on one organization and project. - [Open incidents from Alertmanager, Grafana, Datadog or New Relic](https://realuptime.io/kb/open-incidents-from-alerting-tools): the inbound incident webhook, its generic JSON shape, and the adapters. - [Show a vendor's status on your status page](https://realuptime.io/kb/mirror-vendor-status): mirror a tracked third party from the Outages catalog as a labelled component, RealUptime's own probe reading beside the vendor's own claim, never opening your own incidents. - [Get alerted when a vendor you depend on goes down](https://realuptime.io/kb/vendor-dependency-alerts): watch services from the Outages catalog (the vendor watchlist add-on, on a paid Monitor plan) and hear when one reports an incident on its own status page, and again when it reports it resolved; for a service with no status feed we can read, when our checks of it fail from two or more distant regions, and again when they pass, through your account's own alert channels. - [Install the RealUptime Slack app](https://realuptime.io/kb/slack-app): add RealUptime to a workspace and run /realuptime status or /realuptime incidents from any channel. - [Check if a vendor is down from Slack or Discord](https://realuptime.io/kb/isdown-bot): run /isdown in Slack or Discord to get RealUptime's own reading on a third-party outage, free, with no account required. - [Send subscriber email from your own domain](https://realuptime.io/kb/send-subscriber-email-from-your-domain): DNS records, verification, and the honest fallback to RealUptime's identity, on the Business plan. - [Page on-call through Discord, Teams, Opsgenie, incident.io, FireHydrant, PagerDuty or Slack](https://realuptime.io/kb/page-through-discord-teams-opsgenie): point an escalation step at a notification channel, or let each person choose how they are paged, instead of email only. - [Register Vercel deploys as releases automatically](https://realuptime.io/kb/register-vercel-deploys-as-releases): point Vercel's own deploy-succeeded webhook at RealUptime and skip the CI step entirely. - [Get a weekly digest email](https://realuptime.io/kb/weekly-digest-email): opt-in Monday summary of uptime, incidents, new issues, regressions, top issues and dropped-event totals, with one-click unsubscribe. - [Is it down for everyone, or just me? How to tell in 30 seconds](https://realuptime.io/kb/is-it-down-for-everyone-or-just-me): the diagnostic ladder, per-region readings, and how to rule out your own DNS, ISP, or VPN. - [How to monitor an API your business depends on (vendor watch)](https://realuptime.io/kb/monitor-a-vendor-api-your-business-depends-on): what vendor watch does, the flat-rate add-on and fairness cap, alert semantics, and setup from the real dashboard. - [What a heartbeat check is, and when to use one instead of an HTTP monitor](https://realuptime.io/kb/heartbeat-check-vs-http-monitor): cron and worker monitoring, the ping URL flow, failure semantics, and setup from the real UI. - [What to put on a status page during an incident](https://realuptime.io/kb/what-to-put-on-a-status-page-during-an-incident): templated updates, per-region truth, acknowledgments and internal notes, and why measured components beat hand-flipped checkmarks. - [Uptime SLAs explained: what 99.9 percent actually allows](https://realuptime.io/kb/uptime-slas-explained-what-99-9-percent-actually-allows): the downtime math, comparing a vendor's claim with a check reading of your own, and the permanent outage history behind it. - [How to monitor a cron job](https://realuptime.io/kb/how-to-monitor-a-cron-job): heartbeat wrappers, ping URL placement, grace periods, and the silent-death versus swallowed-error failure stories. - [How to report a failed or stuck cron job run, not just a missed one](https://realuptime.io/kb/report-failed-and-stuck-cron-runs): start and fail pings beside the success ping, exit codes in the alert, a maximum runtime for runs that start and hang, run ids for overlapping runs, and the hold after repeated failures. - [Monitor a Coolify app from outside the server](https://realuptime.io/kb/monitor-a-coolify-app-from-outside-the-server): why Coolify's own health checks die with the host, the agent on the Coolify box, one HTTP check per app, and heartbeats for scheduled tasks. - [Monitor a Railway app: uptime checks and cron heartbeats](https://realuptime.io/kb/monitor-a-railway-app): external monitoring on a managed platform with no server to install on: HTTP checks on the public domain, heartbeats for private workers and cron, and error tracking wired to Railway's deploy variables. - [External uptime monitoring for a Hetzner server](https://realuptime.io/kb/external-uptime-monitoring-for-a-hetzner-server): what provider-side monitoring structurally cannot see, probes from independent regions, the agent for host health, and certificate and cron coverage. - [Monitor Docker containers from outside the host](https://realuptime.io/kb/monitor-docker-containers-from-outside-the-host): why restart policies and HEALTHCHECK are not monitoring, an outside check per exposed service, the agent for host and per-container usage, and heartbeats for workers.