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 LLC, a New Jersey limited liability company (“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; response snapshots of what a failing or recovering page returned; browser-check steps, and the screenshots and failure traces they capture; incident and maintenance text; component names; and the notification destinations you set, such as email addresses, phone numbers, Slack or PagerDuty endpoints, and webhook URLs.
- Status-page subscribers. Each subscriber's email address or, for text alerts, phone number, 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; where enabled, the names of running processes, containers, and services and database metrics; and, only if you configure a log source, short snapshots of recent log lines, which can contain whatever your applications logged.
- AI summaries. Only if you turn on Errors issue summaries or incident insights: the data for the issue or incident being summarized, and the summary generated from it.
- 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 sub-processors in these categories: cloud hosting and database infrastructure in the United States and the EU, including replica and encrypted-backup hosts, and checking probes in the regions on the named list; a network edge provider that carries traffic to our main hostnames and stores browser-check screenshots; transactional email delivery; SMS delivery for status-page subscribers who opt in to text alerts and for SMS notification channels you configure; and, only for accounts that turn on an AI summary feature (Errors issue summaries or incident insights), AI text generation over that account's own data for the item summarized. Vendors that process only RealUptime's own controller-side data, such as our payment processor, company email, and our site and product analytics, which receive none of the data you put into the service, are described in the Privacy Policy and are not sub-processors of your data. Each sub-processor processes personal data only for the service described and only under a written agreement.
The named list, with each vendor's role and region, is available to signed-in account owners in account settings under Data, and by email from support@realuptime.io to any customer or prospective customer evaluating the service. It is deliberately not published on the open web.
Changes. RealUptime will email account owners at least 30 days before a new sub-processor begins processing customer personal data, and the account-settings list is updated at the same time. 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 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, with checking probes also in Canada, the UK, the EU, Japan, Singapore, Australia, and Brazil. 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. Secrets the service must be able to read back, such as integration credentials, are encrypted in the application with AES-256-GCM before they are stored.
- 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, except to anonymize a deleted account's entries. Customers can protect their own sign-in with a passkey or an authenticator app.
- 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 our own measurements of a monitored endpoint and are kept up to three years on every plan; the plan governs the window a customer can see and export, 30 days on Free and 90 days on Growth and Scale, and older results are hidden from those views rather than deleted. Response snapshots, which carry the customer's own content rather than our measurement of it, are held far more briefly: 30 days when captured while a check was failing, 7 days when captured on recovery. Rate-limiting IP addresses are discarded within about two days; 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 the access-control policy that covers access reviews and offboarding is written but not yet formally approved, although the first quarterly access review was completed in September 2026. 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, subscribers, and API keys (metadata only) 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. When an account is deleted, its security audit log entries are anonymized rather than removed, and a phone number that has replied STOP stays on our SMS suppression list so it is never texted again. Browser-check screenshots and traces of a deleted account or check are queued for deletion in the same operation and permanently removed from storage, normally within an hour; deletion is retried until it completes. Accounts that never confirm their email address are deleted 30 days after signup, and free accounts with nothing set up and no sign-in for a year are deleted 30 days after an emailed notice; either deletion works the same way as deleting the account yourself. Retention periods for each 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 the version shown above applies to every account from its effective date. 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, and earlier versions are available on request. Sub-processor changes follow the notice in section 5.
Version 1.6, effective September 26, 2026. Questions about this DPA can be sent to support@realuptime.io, or by mail to:
RealUptime LLC
PMB 1078, 2230 Route 70 W STE 2
Cherry Hill, NJ 08002
United States