Skip to content

Trust

Security at RealUptime

Security work is ongoing. Here is what the service protects today, what we do not claim, and how to report a problem responsibly.

Effective August 4, 2026

Current approach

  • Traffic to the hosted service is encrypted with HTTPS.
  • Passwords are stored as one-way hashes, not readable passwords.
  • Account-owned resources are scoped to the authenticated account.
  • API keys are shown once and stored as hashes.
  • 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: phishing-resistant multi-factor by construction, not a password with a second step bolted on. Customers sign in with a password, a linked Google, GitHub, or Apple account, or a passkey they register themselves (Touch ID, Face ID, Windows Hello, or a hardware security key), 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 enrolment and stores them hashed. Every account activity, including sign-ins, appears in that account's own audit log.

RealUptime does not currently claim SOC 2, ISO 27001, PCI certification, a formal penetration test, or a security SLA.

Access control on your account

An account can hold as many people as your plan allows, each with one of three roles. Owner holds the account itself: its billing, its legal identity, and deletion. Admin runs the product day to day. Responder sees monitors, pages, and incidents and works them, without reaching billing, members, or API keys.

Roles resolve to named capabilities rather than to a rank, so a permission is granted because it was listed and not because a role happened to sit above a line. Reading the audit log is its own capability for that reason: a responder answering a page at 3am has no reason to browse who changed what on the account.

That audit log is the customer's, not a copy of ours. It records who did what to the account and when, including sign-ins. It is append-only, and enforced that way by the database rather than by convention: updates, deletes, and truncation are all rejected by triggers that bind every role, including the one the application connects as, so a correction is a new row and never an edit. Anyone with the capability can read it in account settings or export it as CSV. The same settings area exports the account's full data as JSON at any time, not only on the way out, and deletes the account and everything tied to it on request.

SAML single sign-on and SCIM provisioning are not available today. Members are invited by email and removed by hand, and there is no way to require that sign-in go through your identity provider.

Monitor agent supply chain

The RealUptime Monitor agent is published two ways: as a Docker image and as a release tarball. Both are cosign-signed, with an SBOM and a provenance attestation (builder, git commit, build time) attached to the same digest as the signature, so a verify confirms both who built it and what is in it. The install script (install.sh) verifies the checksum on the tarball path always, and verifies the cosign signature on whichever path it took whenever cosign is present on the machine; when it is absent, the script says so plainly and runs unverified rather than skipping the check silently. Verification is never a hard gate: an unsigned or unverifiable image still runs, the same as it always has for a machine with no cosign installed at all. Verify a pulled image yourself with:

cosign verify --key https://realuptime.io/.well-known/cosign.pub
  ghcr.io/realuptimehq/agent:latest

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 replicas and encrypted backups), transactional email delivery, and payment processing, where card details go to the processor directly and complete card numbers never reach RealUptime.

The named list of sub-processors, with what each can see, is available to signed-in account owners in account settings and on request; see the Data Processing Agreement and the Privacy Policy.

Report a vulnerability

Send reports to security@realuptime.io with the subject “RealUptime security report.” Include the affected URL or feature, reproduction steps, likely impact, and any supporting request or response details. Do not include secrets you do not need to share.

The full vulnerability disclosure policy covers scope, the rules for testing, our response commitment (acknowledge within three business days, triage within seven, fix targets by severity), coordinated disclosure, and safe harbor for good-faith research. The same contact is published in machine-readable form at /.well-known/security.txt (RFC 9116).

Responsible research

When investigating a potential vulnerability:

  • Use your own account and data.
  • Avoid privacy violations, service disruption, social engineering, and destructive testing.
  • Stop if you access another person's information and report it immediately.
  • Give us a reasonable opportunity to investigate before publishing details.

This page is not a paid bug-bounty program and does not authorize testing of third-party systems, denial-of-service activity, physical attacks, or access beyond what is necessary to demonstrate a vulnerability.

What to expect

We review reports regularly and aim to acknowledge a credible report within three business days. Response and remediation time depends on severity and complexity. We will try to keep reporters informed, but this is a target rather than a contractual response-time guarantee.