Skip to content

Privacy

Privacy Policy

RealUptime collects the information needed to run monitoring, accounts, and billing. This page describes that data without claiming controls that are not yet in place.

Effective September 2, 2026

Information we collect

  • Account information, including your email address and password hash.
  • Monitor names, target URLs, status-page content, settings, and regional check results.
  • Error events your applications send to RealUptime Errors, which can include stack traces, request metadata, releases, and tags your code attaches. What an event contains is decided by your code and your project's scrub rules; treat it as data you control and we process (see the DPA).
  • Host metrics reported by the Monitor server agent you install: CPU, memory, disk, load, and process/service names on machines you enroll.
  • Problem reports on the public outage tracker. We store the report category and region and a one-way daily-salted hash used only for rate limiting; we do not store the reporter's IP address, and raw reports are pruned after 7 days (aggregate counts are kept).
  • API-key hashes and integration settings, such as a Slack webhook you choose to provide.
  • Subscription and transaction identifiers from our payment processor when you use a paid plan.
  • Email addresses of people who subscribe to a public status page, and of people who ask for product updates from our site, along with which page the request came from.
  • If you consented to campaign attribution and then created an account, the campaign tag from the link you arrived through, the referring site's hostname, and the page you landed on. This is kept with the account record so we can tell which listings and campaigns are worth continuing. It records the link, not you, it is never updated after the account is created, and it is not used to profile you or shown to anyone outside our own team.
  • Basic request, device, diagnostic, and security logs produced by the service and hosting provider. This includes your IP address, which is used briefly to rate-limit sign-in and subscription attempts and is discarded within 24 hours.
  • Anonymous, aggregate counts of how the site and the signed-in dashboard are used, such as a page loading, a setup step being started, viewed, or abandoned, and a feature being used for the first time. See "Cookies and tracking" below for what that does and does not include; it carries no visitor identifier and is never tied to your account identity.

Payment-card details are entered with and processed by our payment processor; RealUptime does not receive the complete card number. We do not run advertising trackers.

Why we use information

For readers subject to the GDPR, each purpose below names the Article 6(1) legal basis it relies on, since the basis has to be identifiable per purpose rather than asserted once for the whole service (Art. 6 GDPR).

  • Operate monitoring, public status pages, alerts, APIs, and account features. Necessary to perform the contract you signed up for. Basis: contract, Art. 6(1)(b).
  • Send status-page or product-alert messages to a subscriber, by email or SMS. Sent because that address or phone number is on a subscription list the subscriber joined by their own request, whether or not they hold a paid account. Basis: contract, Art. 6(1)(b).
  • Send a welcome or product-update email to someone who asked for updates from our site. This is a distinct purpose from the status-page alert above: it is requested marketing rather than an alert tied to a specific status page. Basis: consent, Art. 6(1)(a), since it is sent because you asked, or, for an existing lead we already have a relationship with, legitimate interest, Art. 6(1)(f), in telling you about the product you use.
  • Process subscriptions and respond to billing or support requests. Basis: contract, Art. 6(1)(b), and, for records tax and accounting law requires us to keep, legal obligation, Art. 6(1)(c).
  • Authenticate users, enforce plan limits, prevent abuse, rate-limit sign-in and subscription attempts, and investigate failures. A short-retention, narrow- purpose use of data such as the IP addresses described above, proportionate to the security risk it addresses. Basis: legitimate interest, Art. 6(1)(f), in keeping the service secure.
  • Improve reliability and comply with valid legal obligations. Basis: legitimate interest, Art. 6(1)(f), and legal obligation, Art. 6(1)(c), as applicable.
  • Understand and improve onboarding and product usage, using anonymous aggregate counts (see "Cookies and tracking" below). This does not identify you and does not affect the service you receive. Basis: legitimate interest, Art. 6(1)(f), in understanding aggregate product usage; in the alternative, this processing does not involve personal data in the first place, since the counts carry no identifier (see "Cookies and tracking"), in which case Art. 6 does not apply to it at all.
  • Set the campaign attribution cookie described below. Basis: consent, Art. 6(1)(a). We do not set this cookie without it.

Cookies and tracking

RealUptime sets no cookies when you browse the public site, with one exception you control, described below. Nothing else is stored on your device until you take a deliberate action, and every other cookie we set is strictly necessary to deliver something you asked for. That cookie promise is about the public site specifically; the cookie-free analytics tool described next runs the same way on every host, including the signed-in dashboard, exactly as the billing and monitor-creation counts already covered here always have:

  • A session cookie, set when you sign in, that keeps you signed in. It holds a random token checked against our server on each request, never your identity. Signed-in product use happens on dashboard.realuptime.io, which sets its own session cookie of the same kind, scoped to that host only.
  • Short-lived sign-in security cookies, set only when you start a Google, GitHub, or Apple sign-in, that protect that exchange against cross-site request forgery. They are deleted as soon as the sign-in finishes.
  • An administrative cookie used only by our own operators for internal tooling.

We use no advertising, marketing, or cross-site tracking cookies, and we do not fingerprint your device or use local storage to identify you. Our analytics tool is served from our own domain and stores nothing on your device: it records a page view, and counts of things that happened on the site or in your signed-in dashboard, such as a signup being completed, a dashboard page loading for the first time, a setup step being started, viewed, or abandoned, or a feature being used for the first time, with no identifier that would let us recognize you on a later visit or on another website. A dashboard-page count can be grouped by coarse buckets, such as roughly how long ago the account was created or whether it has already completed setup, but the count itself never carries your account identity and is never linked back to you individually. One of these counts, whether a setup step was abandoned, is detected using your browser's built-in page-unload signal (so we can tell the step was left rather than finished even if you closed the tab); it reports only which kind of step and where, the same anonymous shape as every other count here, and it fires whether or not you have answered the cookie banner, because none of this depends on a cookie.

The one exception is campaign attribution, and it only ever happens with your consent. A banner asks whether we may set a first-party cookie, named ru_attr, that records which of our own campaign links brought you here. It is set only if you say yes and only when your visit arrived through a link we tagged. It holds the campaign parameters from that link, the referring site's hostname, and the page you landed on. It contains no identifier of you or your device, it expires after 30 days, and it is never shared with or read by any third party. If you go on to create an account, that campaign tag is copied onto the account record and kept with it, as described under "Information we collect" above. If you decline, no attribution cookie is set. Your answer either way is remembered in a small preference cookie, named ru_consent, for 180 days so we do not keep asking; remembering a decline is the only thing that cookie does with a "no". Ignoring the banner is treated the same as declining: nothing is captured without an explicit yes, including when JavaScript is disabled.

We do count how often the banner is answered yes and how often it is answered no, because a measurement nobody can size is not a measurement. That count is a running total and nothing else: it carries no identifier, records nothing about who answered, and is not linked to your visit. Declining is never remembered as anything more than the preference cookie above.

Beyond that one consented cookie, we set nothing that is not strictly necessary for a service you requested, which is why the banner asks a single question instead of presenting a category maze. Blocking cookies in your browser is fine for reading the site, but account features cannot work without the session cookie. If our cookie use ever changes further, we will ask for consent before setting anything that needs it.

Service providers

We use a small number of providers to operate RealUptime, each handling only what its job requires:

  • Hosting and database infrastructure in the United States and the EU, including replica hosts and encrypted-backup storage. This is where your data lives and runs.
  • A transactional email provider that delivers sign-in, alert, and status-update messages, so it processes recipient addresses and message content.
  • An SMS provider, for status pages that offer text alerts, which processes the phone numbers of subscribers who opt in and the content of the alerts sent to them, and receives their STOP/START replies.
  • A payment processor that handles subscriptions and payments. Card details are entered with the processor directly and never reach us.
  • A DNS provider for realuptime.io. It stores no account data.
  • A cookie-free analytics tool providing aggregate site and in-product usage statistics, as described above.
  • Operational tooling: source-code hosting for our deployment pipeline and a paging service that alerts our own on-call operator. Neither holds customer records; both can receive operational alert text about our systems.
  • A public domain-registration (RDAP) lookup service, which receives the domain names you ask us to watch for expiry, and nothing else.

These providers process data on our instructions, and may do so in countries other than your own. Signed-in account owners can see the named list of processors of customer data in account settings, and anyone evaluating the service can request it by email; see the Data Processing Agreement. If you connect Slack, PagerDuty, or a webhook of your own, alert information is sent where you direct it; those are your integrations rather than our providers. We may also disclose information when required by law, to protect the service or its users, or as part of a business transfer. We do not sell personal information, and we do not share it for advertising.

Public status pages

A public page can expose the page name, component names, incident text, monitoring state, latency, regions, and timestamps. Do not place secrets, private endpoints, personal information, or confidential incident details on a public page.

Retention and deletion

Account and configuration data is retained while needed to provide the service. Raw per-check monitoring results are retained for 90 days and then deleted; daily and hourly uptime and latency summaries derived from them are kept longer term to support the history shown on status pages. Error events are retained by plan: 14 days on Free, 90 days on Growth, and 180 days on Scale, then deleted. Raw server-agent metric samples are retained for 7 days, with longer-term rollups kept for history. Raw outage-tracker problem reports are pruned after 7 days; only aggregate counts remain. Operational logs may be kept for a shorter period based on troubleshooting and security needs. Some records may be retained when required for security, billing, or legal reasons.

Your choices and rights

Depending on where you live, you may have rights to access, correct, export, or delete your personal information, to object to or restrict certain processing, and to complain to your local data protection authority. We apply the following to everyone, not only to people in a particular country.

  • Export. Signed-in users can download their account, monitors, status pages, incidents, and subscribers as JSON from account settings, without asking us.
  • Deletion. Signed-in users can delete their account from account settings. This cancels any subscription and removes the account and its monitoring data.
  • Status-page and product-update email. Every one of those messages carries a one-click unsubscribe link, which takes effect immediately.
  • Status-page text alerts. Reply STOP to any alert to stop receiving SMS immediately; we honor it the same way a carrier requires. Unsubscribing or replying STOP stops future messages but keeps the number on a suppression list so we do not re-subscribe it. If you are a status-page subscriber, by email or SMS, and want your address or phone number erased from our systems entirely rather than only unsubscribed or suppressed, email support@realuptime.io and we will delete the record; this is not yet a self-serve control for someone who is not a signed-in account holder.
  • Cookie choice. You can change your answer to the cookie banner at any time, on the control below this list. Turning campaign attribution off also deletes the attribution cookie from this browser.
  • Anything else. For access, correction, or a request the dashboard does not cover, email support@realuptime.io. Requests are handled by a person against a written checklist, not by an automated system, and we aim to respond within 30 days. We will ask you to verify control of the account email before acting on a request.

US state privacy rights

If you live in California or another US state with a comprehensive privacy law, the rights above apply to you under those laws too, including the rights the CCPA and CPRA call access, correction, deletion, and portability. RealUptime does not sell personal information and does not share it for cross-context behavioral advertising, so there is nothing to opt out of under “Do Not Sell or Share”. To make a request, use the self-serve controls in account settings or email support@realuptime.io; we verify requests against the account email and never charge for them or treat you differently for making one. An authorized agent may submit a request for you with proof of your permission.

Security and international processing

We use technical and operational safeguards appropriate to the current service, but no internet service can guarantee absolute security. RealUptime and its providers may process information in countries different from your own.

Children

RealUptime is a business and developer tool and is not directed to children under 13. Contact us if you believe a child has provided personal information.

Changes and contact

We will update this page when our data practices materially change, and the effective date at the top will change with it. Privacy questions and data requests can be sent to support@realuptime.io, or by mail to:

Realuptime
#1078, 2230 Route 70 W STE 2
Cherry Hill, NJ 08002
United States