Account and data security
Traffic to the hosted service is encrypted with HTTPS. Passwords are stored as one-way hashes, never as readable text, and API keys are shown once at creation and stored as hashes afterward. Account-owned resources are scoped to the authenticated account, and production access is kept to the people and services that need it.
Every RealUptime employee signs in to internal systems with a hardware security key or passkey, never a password. Customers sign in with a password, a linked Google, GitHub, or Apple account, or a passkey they register themselves. Customers can add a time-based one-time code from an authenticator app as a second factor. Enrolling that second factor issues ten single-use recovery codes.
An account can hold multiple people, each with one of three roles: Owner (billing, legal identity, deletion), Admin (day-to-day product use), or Responder (monitors, pages, and incidents only, without billing, members, or API keys).
Every account holds its own append-only audit log of who did what and when, including sign-ins. The database itself enforces the log as append-only, rather than convention. Any account can export its full data as JSON at any time, not only on the way out. Any account can also delete itself and everything tied to it on request.
The full write-up, including the current directory-integration (SAML/SCIM) status and how to report a vulnerability, lives at /security.
Data isolation in the database
Row-level security is turned on for every table in the production schema. That is a deliberate, deny-by-default backstop: with no policies defined, a connection that is not the application can read nothing.
The application itself connects through its own dedicated database role, which owns the tables. The application's query and authorization layer enforces which account a request may touch. Every account-scoped endpoint runs through that layer. We are stating this plainly rather than describing it as row-level security enforcing tenant isolation, because that is not the mechanism doing the enforcing today.
Backups
The production PostgreSQL database runs on a dedicated server in a United States data center operated by a hosting sub-processor (named in our sub-processor register), with a replica on a second server.
Independently, an hourly job takes an encrypted logical backup (pg_dump, sealed with age before it ever touches disk). The job ships the backup to object storage at a different vendor from the database it protects, so one vendor's failure cannot take out both the primary copy and its backup. Local and offsite copies are kept on three tiers: hourly, daily, and weekly. A problem discovered days or weeks after it was introduced still has a recoverable point in the history, rather than only the last few hours.
Recovery targets: no more than 2 hours of data loss (RPO) and service restored within 4 hours (RTO). A monthly, fully automated restore drill pages an operator if it fails. The most recent published drill restored 60 tables from the offsite copy in seconds. Row counts were compared against production, zero orphaned rows were found, and the measured RPO was 27 minutes. A separate freshness check watches the independent backup pipeline and the replicas and pages if either goes stale.
Availability: recovery from a hosting outage
The application runs on a cloud application platform, on more than one machine. The database has a PostgreSQL replica on a second server in a different data center, kept in continuous logical replication from production. The encrypted offsite backups described above are held at a different vendor from the database.
There is no automatic failover. If a hosting provider has an outage that the platform does not ride out on its own, recovery is manual. An operator follows a written runbook to promote the replica, or to restore from the offsite backup. The operator then points the service at the recovered database. The replica is read-only until that deliberate, scripted promotion step makes it the primary. The promotion path is rehearsed and measured, not theoretical. Every outage alerts an operator, so a failure is never silent.
Data retention
Uptime check history: full-resolution results are our own measurements and are kept up to three years on every tier, free included. What the tier governs is the window a customer can see and export in the product, 30 days on Free and 90 days on paid tiers. Older results are hidden from those views rather than deleted, and a plan change widens the window retroactively. Downsampled history used to draw longer charts is kept indefinitely on every tier.
Response snapshots are held far more briefly, because that content belongs to the customer and their visitors rather than being our measurement of it. A snapshot captured while a check was failing is kept 30 days. A snapshot captured when a check recovered is kept 7 days. Error tracking event retention is tier-based: 14 days on Free, 90 on Growth, and 180 on Scale. Outage records shown on our free public outage pages are never pruned once created, because they are the permanent record of what was measured.
Every account can export its complete data, or delete the account and everything tied to it, on demand from account settings. Details and the full list of what an export contains are at /no-lock-in.
Sub-processors
A small number of providers process data on RealUptime's behalf, each scoped to what its job requires. The providers cover hosting and database infrastructure (including the replica and encrypted backups described above), transactional email delivery, and payment processing. Card details go to the payment processor directly, and complete card numbers never reach RealUptime.
The named sub-processor list is available to signed-in account owners in account settings, and on request by email. The full legal terms are at /dpa.
Certification: where we stand
RealUptime does not currently hold SOC 2, ISO 27001, or PCI certification, has not had a formal third-party penetration test, and does not offer a contractual security SLA. We are not implying otherwise anywhere on this site.
Pursuing formal security certification, in the SOC 2 direction, is on our roadmap once the business is at a stage that justifies the cost. Audit evidence is already a standing engineering principle. New work that touches customer data, credentials, or operator access is built to produce audit evidence by default: logged mutations, append-only records, attributable actions, and least-privilege access. Certification work later then does not require ripping anything out first.
Card payments are handled entirely by our payment processor through its hosted checkout. The processor is a PCI DSS Level 1 service provider; no card number reaches RealUptime systems, and it requires no merchant PCI submission from us at our volume.
Questions
For a security questionnaire, a vendor-risk review, or anything else procurement needs, write to support@realuptime.io. To report a vulnerability, use security@realuptime.io and see the full vulnerability disclosure policy.