Parties and roles
This Data Processing Agreement (“DPA”) forms part of the Terms of Service between the customer who holds a RealUptime account (“you”, the “Customer”) and Realuptime (“RealUptime”, “we”). It applies whenever RealUptime processes personal data on your behalf and the EU General Data Protection Regulation (“GDPR”), the UK GDPR, or a similar law applies to that processing.
For the personal data you put into the service, you are the controller (or a processor acting for your own controller) and RealUptime is your processor. RealUptime is a controller in its own right for the data it collects about its own customers and visitors, such as your account owner's login details, billing records, and site analytics; that processing is described in the Privacy Policy and is not covered by this DPA.
What is processed
Subject matter and duration. RealUptime processes personal data in order to provide the monitoring, status-page, error-tracking, and server-monitoring services you configure, for as long as you have an account and for the deletion period in section 9.
Nature and purpose. Storing the configuration you provide, running checks against the targets you name, collecting events your own software sends us, sending the notifications you ask for, and showing the results to you, your team, and, for public status pages, to anyone you publish them to.
Categories of data subjects. Your team members and account users; subscribers to your status pages; people who appear in data your software sends to RealUptime Errors or the Monitor agent; and, to the extent a monitored URL or incident text names a person, those people.
Categories of personal data, by product line, as the service is built today:
- Account and team. Email addresses, names, and display names of account owners and team members; the IP address and user agent attached to sign-ins and to entries in your account's audit log.
- Uptime monitoring and status pages. Monitor target URLs, hostnames, and ports; the response assertions you configure, including header names and expected values; check results from each probe region; incident and maintenance text; component names; and the notification destinations you set, such as email addresses, Slack or PagerDuty endpoints, and webhook URLs.
- Status-page subscribers. Each subscriber's email address, confirmation state, the IP address from which they subscribed, and the components they follow. Subscribers you import in bulk are stored unconfirmed and are deleted after 30 days if they never confirm.
- RealUptime Errors. Error events sent by the SDKs: message, stack frames, release, runtime, and the tags, context, and identity fields your code attaches. Our SDKs scrub authorization headers, cookies, and card- and token-shaped strings before an event leaves your process, and user email and username are replaced with a placeholder unless you opt a field back in; our server applies the same rules again on receipt. Identifiers you choose to send as-is, such as a user id, are stored as sent.
- RealUptime Monitor (server agent). Host metadata reported by the agent: hostname, operating system and version, architecture, cluster and node labels; CPU, memory, disk, and network samples; and, where enabled, the names of running processes, containers, and services.
- Audit log. An append-only record of actions taken in your account and, for our own staff, any access to your account, each with the acting person's email, IP address, and user agent.
Special categories. The service is not designed for sensitive data. You agree not to send special-category data (health, biometric, political, religious, or similar) to RealUptime, and not to place personal data on a public status page.
RealUptime's obligations as processor
In line with Article 28(3) GDPR, RealUptime will:
- (a) Process only on your documented instructions. Your instructions are the Terms, this DPA, and the configuration you set in the product. RealUptime will not process personal data for any other purpose unless required by law, in which case we will tell you first unless that law prohibits it.
- (b) Keep it confidential. Every person RealUptime authorizes to process personal data is bound by a confidentiality obligation. Staff access to customer data is limited to what support, operations, and security work require, and every such access is written to the audit log with the staff member's identity.
- (c) Secure it. Apply the technical and organizational measures in section 7, which RealUptime may update as long as the overall level of protection does not go down.
- (d) Manage sub-processors as set out in section 5, engaging them under written terms no less protective than this DPA and staying responsible to you for their performance.
- (e) Help you answer data-subject requests. The dashboard lets you export and delete your own data; for anything it does not cover, we will assist within a reasonable time, taking into account the nature of the processing.
- (f) Help you with security, breach notification, and impact assessments, including notifying you of personal-data breaches as described in section 8 and providing the information reasonably needed for a data protection impact assessment or a consultation with a supervisory authority.
- (g) Delete or return the data when the service ends, as described in section 9.
- (h) Demonstrate compliance and allow audits as described in section 10, and tell you promptly if we believe an instruction of yours infringes data protection law.
Your obligations
You are responsible for the lawfulness of the personal data you provide, for having a legal basis and any required notices or consents for collecting it, for keeping your account credentials and API keys secure, and for configuring the product appropriately: for example, not monitoring URLs that carry credentials or personal identifiers, using the Errors SDK scrubbing defaults unless you have a reason not to, and not publishing personal data on a public status page.
Sub-processors
You give RealUptime general authorization to use the sub-processors below. Each one processes personal data only for the service described and only under a written agreement. This list is also available as JSON at /dpa/subprocessors so you can monitor it automatically.
| Vendor | Service | Personal data | Location |
|---|---|---|---|
| Supabase | Hosts the production PostgreSQL database. | All customer data: accounts and users, monitors and check results, status pages and subscribers, incidents, Errors events, Monitor agent metrics, audit logs, billing references. | United States (AWS us-east-1, Northern Virginia) |
| Fly.io | Runs the web application, the API and MCP server, and the regional checking probes. | All customer data in transit and in process memory while serving requests; operational request logs; monitor target URLs and probe results. | United States (Ashburn, Chicago, San Jose), Germany (Frankfurt), Japan (Tokyo) |
| OVHcloud | Operations host: a streaming replica of the production database, the warm standby application, and encrypted local backups. | A replica of all customer data; encrypted backup archives. | United States (Hillsboro, Oregon) |
| Contabo | Second operations host at an independent provider: a streaming replica of the production database and encrypted backups. | A replica of all customer data; encrypted backup archives. | European Union (Contabo "Hub Europe" region) |
| Cloudflare | DNS for realuptime.io and R2 object storage for offsite database backups. | Offsite backup archives, encrypted before upload so Cloudflare holds ciphertext only. | Cloudflare's global network; R2 backup buckets use Cloudflare's automatic placement and are not pinned to one jurisdiction |
| Resend | Primary transactional email delivery (sign-in, alert, status-page, and incident messages). | Recipient email addresses and message content, which can include monitor names, incident text, and status-page names. | United States (sends through Amazon SES, us-east-1) |
| Postmark | Fallback transactional email delivery, used only if Resend is unavailable. | The same as Resend, only while the fallback is active. | United States |
| Stripe | Subscription billing and payments. | Billing email address, subscription and invoice records. Card details are entered with Stripe directly and never reach RealUptime. | United States |
| Google Workspace | Company mailboxes, including support@realuptime.io. | Whatever you send us by email: your name, email address, and the content of support, privacy, and legal correspondence. | United States |
| PagerDuty | Pages RealUptime's own on-call operator when our service is degraded. | Operational alert text about our own systems. No customer records, and customer-configured PagerDuty integrations are the customer's own service, not this one. | United States |
Several other vendors appear in our operating record but do not process customer personal data. They are listed here so nothing is hidden:
| Vendor | Service | Personal data | Location |
|---|---|---|---|
| GitHub | Source code hosting and deployment pipeline. | None. Holds our code, not customer records. | United States |
| Amazon Route 53 | Second DNS provider for realuptime.io. | None. DNS records only. | United States |
| Umami | Aggregate site analytics, served from our own domain. | Page views with no visitor identifier, cookie, or IP-based profile. See the Privacy Policy. | Vendor-hosted; receives no personal data under this agreement |
| rdap.org | Public domain-registration lookups for domain-expiry monitors. | The domain names you ask us to watch, and nothing else. | Public lookup service |
Changes. RealUptime will update this page and the JSON list at least 30 days before a new sub-processor begins processing customer personal data, and will email account owners with the change. If you object on reasonable data-protection grounds within that period and we cannot resolve the objection, you may terminate the affected service and we will refund any prepaid fees for the period after termination. Replacing a vendor in an emergency to keep the service running is allowed without advance notice; we will post and email the change as soon as practicable afterwards. Integrations you connect yourself, such as your own Slack, PagerDuty, or webhook endpoints, are your recipients and not our sub-processors.
International transfers
RealUptime is operated from the United States and its sub-processors are mainly located there. Where personal data subject to the GDPR is transferred to a country without an adequacy decision, the parties rely on the European Commission's Standard Contractual Clauses (Decision (EU) 2021/914), Module Two (controller to processor), which are incorporated into this DPA by reference, with you as data exporter and RealUptime as data importer, the optional docking clause included, Option 2 of Clause 9 (general authorization) with the notice period in section 5, Clause 17 governed by the law of Ireland, and Clause 18 courts of Ireland. Annex I is section 2 of this DPA, Annex II is section 7, and Annex III is section 5. For transfers subject to the UK GDPR, the UK International Data Transfer Addendum to the EU SCCs (version B1.0) is incorporated by reference and the tables in it are completed by the same sections. If a sub-processor processes personal data in a third country on our behalf, we rely on the same or equivalent safeguards in our agreement with that sub-processor.
Security measures
The measures RealUptime applies today. This is an honest description, not a certification claim: RealUptime does not currently hold a SOC 2 report, ISO 27001 certification, or an independent penetration-test report, and does not claim one here. The Security page carries the current state and how to report a vulnerability.
- Transport encryption. All traffic to the service, including the API, agent and SDK ingest, and public status pages, is served over HTTPS.
- Credentials. Customer passwords, API keys, agent tokens, and session tokens are stored as one-way hashes, never in readable form. API keys and agent tokens are shown once at creation.
- Access control. Every resource is scoped to the account that owns it. Production access is limited to the people and systems that need it. Staff sign in to internal tooling with a hardware security key or passkey, not a password, and every staff action and every staff view of a customer account is written to an append-only audit log that the database itself refuses to update or delete.
- Isolation of public and staff surfaces. Customer status pages, the customer dashboard, and the staff console run on separate origins, behind a content-security policy that allows no third-party hosts.
- Backups and recovery. The production database is backed up on a schedule to two independent hosts and to offsite object storage. Every backup archive is encrypted before it leaves the host that produced it, and restores are drilled on a monthly cadence against a disposable database.
- Monitoring and on-call. The service is watched by an independent self-monitor that pages an operator when checking, alert delivery, or the database degrades, and a warm standby can take over the application on failure.
- Data minimization. Raw check results are kept for 90 days and then deleted; rate-limiting IP addresses are discarded within 24 hours; Errors SDKs scrub sensitive values before sending; Monitor agent raw samples are kept for 7 days before being summarized.
- Change management. Every change to the service goes through a pull request, automated tests, and a gated deploy; database migrations are applied deliberately, never automatically.
What is not in place yet, stated plainly: no independent audit report; encryption at rest for the primary database and offsite storage relies on the hosting providers' defaults rather than a setting RealUptime enforces and evidences; and there is no written access-review or offboarding procedure yet, because the company currently has a single operator and no staff to review or offboard. Each of these is on the readiness plan and this section will change when they do.
Personal-data breach notification
If RealUptime becomes aware of a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data we process for you, we will notify the account owner's email address without undue delay, and in any case within 72 hours of becoming aware. The notice will describe the nature of the breach, the categories and approximate number of data subjects and records affected as far as we know them, the likely consequences, the measures taken or proposed, and a contact point. We will follow up as we learn more and cooperate reasonably with your own notification duties. Notifying you is not an admission of fault.
Deletion and return
While your account is open you can export your account, monitors, status pages, incidents, and subscribers as JSON from account settings at any time, and delete individual records or the whole account yourself. Deleting the account removes the account and its monitoring data from the production database and its replicas; copies then age out of the encrypted backup sets, the longest of which is kept for 12 weeks. On termination of the service for any reason, RealUptime will delete the personal data it holds for you on the same basis, unless a law requires us to keep specific records, in which case we keep only those, only for as long as required, and continue to protect them under this DPA. Retention periods for every category of data are listed in the Privacy Policy.
Audit and information rights
RealUptime will make available the information reasonably necessary to demonstrate compliance with this DPA: this page, the Security page, the sub-processor list, and answers to reasonable written security questionnaires. When an independent audit report exists it will be offered under confidentiality in place of an on-site audit. Where those materials are not enough to meet a legal obligation of yours, you may conduct, or have an independent auditor bound by confidentiality conduct, an audit of RealUptime's processing once in any twelve-month period, or after a breach affecting your data, on at least 30 days' written notice, during business hours, without disrupting the service, and at your expense. We will cooperate reasonably with any such audit.
Liability and precedence
Each party's liability under this DPA is subject to the limitations and exclusions in the Terms of Service. If this DPA conflicts with the Terms on a matter of data protection, this DPA prevails; if it conflicts with the Standard Contractual Clauses, the Clauses prevail. Nothing in this DPA limits either party's obligations to data subjects under data protection law.
How this DPA is executed
This DPA is accepted by reference when an account owner agrees to the Terms of Service, and it applies to every account from the effective date above. No signature is needed for it to bind both parties. If your procurement process needs a countersigned copy, email support@realuptime.io with the subject “DPA”, your account owner's email address, and your legal entity name, and we will return a signed PDF of this version. We do not negotiate bespoke terms on self-serve plans.
Changes. When this DPA changes, the version number and effective date at the top change with it, the previous version stays available on request, and account owners are emailed about material changes. Sub-processor changes follow the notice period in section 5.
Version 1.0, effective August 23, 2026. Questions about this DPA 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