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, and can add a time-based one-time code from an authenticator app as a second factor, which issues ten single-use recovery codes at enrollment.
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, enforced append-only by the database itself rather than by convention. Any account can export its full data as JSON at any time, not only on the way out, and delete the account 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 against Supabase's auto-generated public data API: with no policies defined, that API can read nothing. The application itself connects through its own dedicated database role, which owns the tables and enforces which account a request may touch in the application's query and authorization layer, the same layer every account-scoped endpoint runs through. 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
Production PostgreSQL runs on Supabase, which takes its own managed daily physical backups. Independently, an hourly job takes an encrypted logical backup (pg_dump, sealed with age before it ever touches disk) and ships it to Cloudflare R2, 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, so 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, with row counts compared against production and zero orphaned rows found, at a measured RPO of 27 minutes. A separate freshness check watches both the independent backup pipeline and Supabase's own managed layer and pages if either goes stale.
Availability: DNS failover and database replication
The application runs on Fly.io. Independently of that, a warm standby copy of the application runs on infrastructure at a second, unrelated hosting provider, backed by its own PostgreSQL replica kept in continuous logical replication from production. An automated controller checks the primary origin every minute and, after three consecutive failures, flips DNS to the standby; it fails back automatically after ten consecutive successes, and it refuses to fail over at all if the standby itself is not healthy, because moving traffic to a broken standby turns a partial outage into a total one. Every flip is written to two independent DNS providers and triggers an alert, so a failover is never silent.
What this buys: the service survives a Fly.io outage, or a facility-level failure at Fly's primary region, without a human needing to be awake. What it does not buy on its own: surviving an outage of the underlying database's own region while still accepting writes there, because the replica is read-only until a deliberate, scripted promotion step makes it the primary. That promotion path is rehearsed and measured, not theoretical.
Data retention
Uptime check history: full-resolution results are kept 30 days on the Free tier and 90 days on paid tiers; downsampled history used to draw longer charts is kept indefinitely on every tier. 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: hosting and database infrastructure (including the replica and encrypted backups described above), transactional email delivery, and payment processing, where card details go to the processor directly and complete card numbers never reach RealUptime.
The current, named sub-processor list, what each one can see, and 30 days' advance notice before any new one is added, is published and kept current at /dpa/subprocessors (also available as JSON for vendor-management tooling), with the full legal terms 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, and it is a standing engineering principle already: 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, least-privilege access) so that certification work later does not require ripping anything out first.
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.