Trust & Security
Security, privacy, infrastructure, and data protection at StatusPage.me — a two-minute overview, with links to the full detail.
Start Free TrialLast updated: October 3, 2026
Security at a glance
Infrastructure & data residency
| Persistent application data | Hosted in Germany (EU). The production application and database run at netcup in Nuremberg; first-party mail, encrypted off-site backups, a read-only disaster-recovery copy of the database, and a rollback environment run at Contabo in Munich. Provider roles are listed under Subprocessors. |
| Monitoring / probe network | Uptime checks run from a global network of monitoring locations spanning North & South America, Europe, Africa, and Asia-Pacific — this is intentionally global, not EU-only, so accurate multi-region uptime data can be produced. The current locations are listed on the Monitoring network page. They are hosted with several infrastructure providers, and a subset in EU member states forms our EU Monitoring Stack; that term describes where monitoring checks execute, not where all data is processed. |
| Subprocessors | A dated, public catalog lists every provider, its purpose, and its location. See Subprocessors. |
Because monitoring runs globally, transient check traffic can originate outside the EU even though persistent customer data does not leave Germany. See Security for the full breakdown.
Authentication & access
| Password protection | Argon2id hashing; HaveIBeenPwned breach checking at signup/change. |
| Two-factor authentication | TOTP and WebAuthn passkeys/security keys, for both user and admin accounts. |
| Session security | Secure, HttpOnly session cookies; a password change or admin-forced ban invalidates every active session for that account immediately. |
| Role-based access | Team members hold Owner, Admin, Editor, or Viewer roles with different permissions on shared resources. |
Full detail: Security → Authentication & Access.
Encryption & credential protection
We're precise about which of these apply where — hashing, encryption, and "never returned to the client" are different properties, and we don't collapse them into one umbrella claim.
| In transit | TLS with HSTS everywhere, including custom domains (auto-HTTPS via Let's Encrypt). |
| Hashed (irreversible) | Passwords (Argon2id) and API keys (a SHA-256 digest of a random token; the full key is never stored). |
| Encrypted (recoverable) | OAuth access/refresh tokens and select integration secrets, with AES-256-GCM. This is a scoped set of fields, not a blanket "database encrypted at rest" claim. |
| IP addresses | Reduced before they are stored in the database: truncated to a network prefix for page-view, tool and error records, or replaced by a keyed HMAC-SHA256 token for audit and abuse records. These are different mechanisms, described in Security → IP addresses. |
| Never returned to the client | Existing monitor request credentials (custom headers, query parameters, body, and auth fields) are omitted from monitor read responses and never re-rendered into the edit form as plaintext. |
Full detail: Security → Encryption.
Application security
| CSRF | Session-bound tokens on state-changing requests across the dashboard and admin panel. |
| SSRF | Outbound requests from user-supplied monitor/webhook targets block private, loopback, link-local, and cloud-metadata IP ranges, with redirect re-validation. |
| Rate limiting | Per-IP limits on authentication, the public API, and public status-page rendering, with escalating temporary blocks. |
| Uploads | Avatar/logo SVG uploads are validated and sanitized before storage. |
Full detail: Security → Application Security.
Privacy & data protection
| Analytics | Self-hosted, cookie-free Plausible Community Edition — no third-party ad/analytics trackers. |
| Cookies | Essential cookies only: the sign-in session and form (CSRF) protection, plus private-status-page authentication where that feature is used. No advertising, marketing-attribution, or third-party analytics cookies. Details: Privacy-Friendly Overview → Cookies. |
| IP addresses | Truncated or replaced by a keyed token before database storage. Short-lived server request logs can still contain the connecting address; see Security → IP addresses. |
| Sale of personal data | We do not sell personal data. (Policy commitment — see Privacy Policy.) |
| Your rights | GDPR/CCPA access, correction, portability, and deletion rights — see Privacy Policy for the full list and how to exercise them. |
Full detail: Privacy Policy · Privacy-Friendly Overview.
Retention & deletion
Closing your account immediately flags it as closed, and your data is scheduled for removal from active systems under our retention policy. The retention periods and how they apply are set out in the Privacy Policy.
For the full policy, or to confirm your data has been removed, see our Privacy Policy or contact privacy@statuspage.me.
Backups & recovery
Automated daily database backups are encrypted before they leave the database host and copied to an off-site location; the newest generations are also kept locally. Timestamped application backups are taken on every deployment. We rehearse restores, including a full off-site decrypt-and-restore drill after the September 2026 infrastructure move.
Replication and backups are different things. An asynchronous, read-only PostgreSQL standby in a second German city, at a different provider, shortens recovery if our primary database host is lost. Failover is manual, recent transactions could be lost, the application tier is not duplicated, and a production failover has not yet been rehearsed. See Security → Backups & Recovery for scope, recovery targets and the documented restore procedure.
Server Agent (optional)
The optional Server Agent is open source and runs on your own hosts. It sends a fixed, documented list of numeric host metrics outbound over HTTPS, and it does not execute commands sent by the server. Updates are never pushed: you run serveragent --update (or the installer's one-time --upgrade for older agents) yourself, and the download is verified against a published checksum before anything is replaced.
Full detail: Security → Server Agent · source code.
Subprocessors
We maintain a public, dated list of the service providers and subprocessors we use, what they do, and where they're located — including hosting, our global monitoring network, and optional integrations you configure yourself.
View all subprocessorsIncident response
We monitor our own infrastructure with the same multi-region checks we offer customers, and publish incidents on our own public status page. We don't currently offer a formal incident-response SLA or a 24/7 SOC — see status.statuspage.me for live status and history.
Vulnerability reporting
Found a security issue? Email security@statuspage.me with details and reproduction steps. We don't run a paid bug-bounty program, but verified reporters can be credited in our public acknowledgements list.
See Security → Report a vulnerability and our Responsible Disclosure policy.
Compliance & transparency
We have not completed a formal SOC 2, ISO 27001, or PCI DSS audit, and don't claim one. We'd rather tell you plainly what we have and haven't done than imply a certification we don't hold. The controls we do operate, such as Argon2id password hashing, two-factor authentication, audit logging, encrypted database backups and TLS with HSTS, are described on the Security page.
Full disclosure list: Security → What we don't have (yet).