StatOSS
Log inSign upCreate a status page
Open dashboard

Security

Last updated 29 September 2026

Hosting

  • The database is on a server in Denmark (Webdock).
  • A standby server in Germany (Hetzner) keeps a live copy.
  • Checks run from Denmark, Germany and the United States. Check locations store nothing. Their logs name the host of a failed check.
  • Other companies that process data are on the subprocessors page.

Backups and failover

  • Continuous backup to Cloudflare object storage in Western Europe, restorable to any five-minute point in the last 7 days.
  • A daily copy on the server, kept 14 days.
  • A weekly test restore from the offsite backup.
  • If the Danish server stops, the German one serves status pages within a minute and takes over after three. These are drill times, not a guarantee. Up to about a minute of changes can be lost.

Monitors

  • Request headers and bodies set on a monitor, which can include credentials, are stored encrypted and sent to the check locations.
  • Checks store the status, response time and error. Not the response body.
  • Checks cannot reach private addresses or cloud metadata.

Encryption

  • HTTPS for browser and API traffic, and from Cloudflare to our servers. HSTS on statoss.com.
  • Email is sent to Amazon SES over TLS.
  • Backups are encrypted at rest (AES-256). Server disks are not.
  • Monitor headers and bodies, alert destinations, and webhook URLs and secrets are encrypted in the database (AES-256-GCM). The key is kept outside the database and its backups.
  • Passwords are stored as scrypt hashes.
  • API keys are stored as SHA-256 hashes and shown once.
  • Webhook alerts are signed.

Access

  • One person runs StatOSS and has access to the servers and provider accounts.
  • A trusted person can get access through password manager emergency access, after a waiting period. Runbooks are in the code repository.
  • Two-factor sign-in on every provider account.
  • SSH by key only. Secrets are in a file only its owner can read.
  • The database has no network port.
  • Code reaches the servers only as tagged releases built by GitHub Actions.

Teams

All teams share one database. Every request checks that the person or API key belongs to the team that owns the data.

Network

  • All traffic passes through Cloudflare. The servers accept web traffic only from Cloudflare and each other. The German server is also behind Hetzner's firewall.
  • Sign-in is rate limited. Sign-up, password reset and subscribe forms use Cloudflare Turnstile.
  • Form emails are limited to three an hour per inbox, and ten a day except password resets and private page sign-in links.
  • Public status pages load no analytics or tracking. The only cookies open a password-protected or private page.

Accounts

  • Email sign-up needs a confirmed address and a password of at least 10 characters. Google and GitHub sign-in are also available; their tokens are not kept.
  • Two-factor sign-in with an authenticator app, for every account. A team can require it.
  • Sessions end at sign-out or within 7 days of last use.
  • Team owners and admins manage people and API keys. Billing is the owner's. People who leave lose the API keys they made.
  • API keys are read-only or read-write, for one page or all.

Logs

  • No web access log.
  • Error logs keep a visitor's address shortened to its network.
  • The app log names an email address when mail to it fails or is held back.
  • Logs are kept until they reach 250 MB or the next release.
  • Sessions keep the IP address and browser they started from.

Changes

  • Every change must pass lint, type checks, tests and browser tests before release. There is no second reviewer.
  • Operating system security updates install daily. Reboots are done by hand.
  • Dependabot proposes dependency updates weekly and security fixes at once. A known high or critical vulnerability in a dependency stops a release. Images are scanned weekly.
  • No external security test yet.
  • No SOC 2 or ISO 27001 report.

Leaving

Deleting a page or account removes it at once. Bounced-mail records go within 30 days and backups within 16 days. See the data processing agreement.

Incidents

  • Outages are posted on status.statoss.com.
  • A breach of customer personal data is reported to the customer by email within 72 hours of discovery.

Reporting a vulnerability

Email [email protected] with "Security" in the subject. We take no legal action against good-faith research that does not access other people's data or degrade the service, and that gives us time to fix the problem before publishing. See security.txt.