Last updated: October 3, 2026
Table of Contents
Overview
StatusPage.me is a small, independent, privacy-focused company. We store your data on the same infrastructure we rely on ourselves - that alignment keeps us honest. This page describes the concrete technical measures we use. No marketing fluff, no badges we haven't earned.
Authentication & Access
| Password hashing | Argon2id - the current recommended algorithm (stronger than bcrypt/scrypt) |
| Breached password detection | Passwords are checked against the HaveIBeenPwned database using k-anonymity (your password never leaves our servers) |
| Two-factor authentication | TOTP (authenticator app) and WebAuthn security keys and passkeys, for both user and admin accounts |
| Role-based access control | Team roles: Owner, Admin, Editor, Viewer - with per-status-page access scoping |
| Session management | Forced session invalidation on password change, secure & HttpOnly cookies in production |
| OAuth sign-in | Google and GitHub with state validation |
| Single sign-on | Dashboard OIDC on Business and Enterprise; Microsoft Entra ID, Google Workspace, and generic OIDC for viewers of eligible private status pages. Dashboard SAML is not currently available. |
| API keys | Scoped permissions; only a SHA-256 digest and a short display prefix are stored (the full key is not), with revocation support and last-used tracking |
| Support access | Our team enters a customer account through Temporary Support Access (short-lived, approved by you, logged and visible to you). An emergency access path that can start without your prior approval also exists; it is recorded in the audit log, and you are notified by email and in the app that it was used. Administrators can also view account details in the admin panel |
| Security alerts | Email notifications on password changes, 2FA changes, and other account-sensitive actions |
Docs: Account Security & Password Protection, Temporary Support Access (TSA), Teams
Application Security
| SQL injection | All database queries use parameterized statements - no string concatenation of user input into SQL |
| XSS prevention | Server-side template auto-escaping is the primary defense. A Content-Security-Policy header is also sent, but it is permissive today (it allows inline scripts and broad sources) and should not be read as a strict CSP. |
| CSRF protection | Cryptographic CSRF tokens on all state-changing requests (forms and API calls) |
| SSRF protection | Server-side URL fetching blocks all private/internal IP ranges (RFC 1918, loopback, link-local, IPv6 ULA) |
| Rate limiting | Authentication endpoints, API calls, and public tools are rate-limited per IP |
| Request timeouts | A 30-second per-request context timeout bounds database work to prevent resource exhaustion |
Infrastructure
| Production hosting | Germany (EU). The application components, PostgreSQL primary, Redis cache and scheduler run at netcup in Nuremberg. Provider roles are listed on Subprocessors. |
| Other hosted services | Contabo in Munich, Germany, hosts our first-party mail server, receives the encrypted off-site backups, hosts the disaster-recovery database standby described below, still holds a retained rollback environment from the previous primary, and is one of our monitoring locations. |
| Database disaster recovery | An asynchronous, read-only physical PostgreSQL standby of the production database runs at Contabo in Munich, a different provider and a different city from the Nuremberg primary (both in Germany). It receives changes continuously over a restricted, key-authenticated SSH tunnel, using a dedicated database role that can replicate but has no other privileges, with SCRAM-SHA-256 authentication. Promotion is manual. What this does and does not protect is set out under Backups & Recovery. |
| Database access | PostgreSQL listens on loopback only and is not exposed on a public network interface. The application authenticates to it with SCRAM-SHA-256 password authentication. |
| Architecture | 5 isolated service components (website, status pages, user dashboard, admin, scheduler) running as separate processes |
| Health monitoring | Per-component health checks with automatic routing - unhealthy components are removed from load balancing |
| Monitoring network | Uptime checks run from a global network of monitoring locations. The current list is on Monitoring network; the network is intentionally not EU-only. Monitoring nodes receive the monitor configuration and telemetry needed to run customer-configured checks. A subset of locations in EU member states forms our EU Monitoring Stack, which describes where checks execute and is not a data-residency guarantee for other processing. |
| Security headers | HSTS (with includeSubDomains), X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection and a Content-Security-Policy header |
| Network protection | Network-level DDoS filtering is provided by our hosting provider, with edge TLS termination and request handling via Caddy |
Encryption
| In transit | TLS everywhere with HSTS enforced. Automatic HTTPS for all domains including customer custom domains via Let's Encrypt. |
| Sensitive data at rest | Selected fields are encrypted with AES-256-GCM: dashboard OIDC client secrets, OAuth access and refresh tokens, and Microsoft Graph integration secrets. This is not a blanket full-database or storage-volume encryption claim. |
| Passwords | Irreversibly hashed with Argon2id (never stored in plaintext or reversible form) |
| API keys | Stored as a SHA-256 digest of a random token (a hash, not encryption) |
| Database backups | Encrypted before they leave the database host; see Backups & Recovery for scope |
| IP addresses | Reduced before they are stored in the database (truncated or keyed-token, not encrypted); see IP addresses & logs |
IP addresses & logs
| Page views, tool checks, error records, heartbeat pings | Truncated before storage: IPv4 addresses to a /24 network prefix, IPv6 addresses to a /48. Truncation keeps coarse network information and cannot be reversed. |
| Security, audit and abuse-detection records | Replaced by a keyed HMAC-SHA256 token. The key is held outside the database; if no key is configured the address is dropped rather than stored. The same source produces the same token, which is what lets us recognise repeat abuse. |
| API key usage logs | A secret-salted SHA-256 digest. Storing the raw address is off by default and is not enabled in production. |
| Rate limiting | Done in memory; nothing about it is written down. |
| Server request logs | The application servers keep an operational request log in the server's system journal that includes the connecting IP address. It is used for troubleshooting and abuse handling, is not copied into the application database, and rotates automatically by size; we have not configured a fixed time limit for it. Our reverse proxy does not write access logs. |
| Older records | A small number of records created before this reduction was introduced may still contain full addresses. |
Truncation, keyed hashing (HMAC-SHA256), plain SHA-256 and encryption are different things and are not interchangeable. The code is open source: hsp-ip-anonymizer. See also the Privacy-Friendly Overview.
Data Protection & Privacy
| Data deletion | Closed accounts are scheduled for removal from active systems under our retention policy. See our Privacy Policy for retention details. |
| Account closure | Self-service account deletion immediately flags the account as closed and queues it for data removal |
| Subscriber management | Double opt-in confirmation, one-click unsubscribe, bulk export and deletion |
| Data export | A portable export of workspace configuration and service data is available from account settings |
Backups & Recovery
| Database backups | Automated daily backups of the databases and global objects (roles, permissions) |
| Encryption scope | Database backup artifacts are encrypted before they leave the database host (AES-256 stream encryption with an RSA-wrapped key, signed with a separate key). The private recovery key is held offline and is not on the production or off-site hosts. This covers the database backups only; application binary backups and the live database volume are not covered by it. The Munich standby is a live replica, not a backup artifact, so this encryption does not apply to it, and we make no disk- or volume-encryption claim for either the primary or the standby. |
| Off-site copy | The encrypted backup is transferred over SSH to a separate provider and location, checksum-verified, and kept there for 14 days |
| Local retention | Daily, weekly and monthly rotation, plus the newest two complete generations kept separately |
| Application backups | Timestamped binary backups on every deployment with 5-version retention |
| Recovery targets | RPO: 24 hours (daily backup interval). RTO: ~30 minutes (restore + restart). These are targets for restoring from a backup, not guarantees, and they do not describe promoting the standby, for which we have no rehearsed figure. |
| Restore testing | A monthly restore-to-temporary-database test is part of our runbook, and we completed a full off-site decrypt-and-restore drill after the September 2026 infrastructure move |
| Database standby (disaster recovery) | Changes on the Nuremberg primary are replicated continuously and asynchronously to the read-only standby in Munich. Replication lag and the replication slot are watched by automated guards on both hosts, and the WAL the primary may retain for the standby is capped so that a stalled standby cannot fill the primary's disk. The standby covers the database tier only: there is no duplicate application stack in Munich. |
| Replication, HA and DR | Replication is not a backup: a mistaken deletion, a dropped table or corruption replicates to the standby within seconds, so the encrypted backups above remain our recovery path for data-level mistakes. Replication is asynchronous, so if the primary were lost, transactions the standby had not yet received could be lost; we do not claim zero data loss. There is no automatic failover and no synchronous or active-active replication. Promoting the standby is a manual decision that follows a documented procedure, and a production failover has not yet been rehearsed. |
Server Agent
| What it is | An optional, open-source agent you install on your own hosts (source). It pushes a fixed list of numeric host metrics (CPU, memory, load, disk, network) outbound over HTTPS every 60 seconds. serveragent -metrics prints exactly what it collects. |
| No remote control | It does not execute commands sent by the server, accepts no instructions from the server, and never downloads or runs code on its own. There is no inbound control channel. |
| Updates are operator-triggered | You decide when to update. serveragent --update (available from v0.1.4) downloads the current release from our endpoint, verifies its SHA-256 checksum and runs it once as a self-check before atomically replacing the binary; it does not restart the service. Agents older than v0.1.4 update once with the installer's --upgrade mode, which keeps the existing configuration. The dashboard shows when an update is available and the exact command; nothing is pushed to your host. |
| Least privilege | The installer runs the agent as a dedicated unprivileged system user under a hardened systemd unit (read-only filesystem apart from its own spool, no new privileges, empty capability set, syscall filter, memory and CPU caps). |
| Credentials | Each server has its own ingest key, shown once when the server is added and replaceable from the dashboard. |
Docs: Server monitoring
Operational Security
| Deployment safety | Automated pre-deploy backups, post-deploy health monitoring, and automatic rollback when the post-deploy health check fails |
| Dependency integrity | Go module checksums are verified (go mod verify) as part of our standard deployment procedure |
| Audit logging | Administrative actions, authentication events, impersonation sessions, and data changes are logged with timestamps and actor context |
| Error log sanitization | Authorization and Cookie headers are automatically redacted from error logs |
| Monitoring ourselves | We run the same multi-region checks on our own infrastructure that we offer customers, and publish incidents on our own status page |
Uptime & SLA
We target 99.9% monthly uptime for the StatusPage.me platform. Our own status page is public - you can verify our track record anytime:
We use multi-region uptime monitoring with quorum-based alerting to minimize false positives. Automated deployment rollbacks help us recover from bad releases within minutes, not hours.
Compliance status
We hold no SOC 2, ISO 27001 or PCI DSS certification and have not completed a formal audit for any of them. The controls we operate are described on this page, and we answer specific questions from your compliance team directly.
Payment card data is handled by our Merchant of Record, DodoPayments, and never reaches our servers. Agreements and lists: Privacy Policy, Data Processing Agreement, Subprocessors.
What we don't have (yet)
Transparency matters. Here's what we're working toward or have not completed:
| SOC 2 / ISO 27001 certification | We have not completed a formal audit and hold no certification. The controls we operate are described on this page, and we're happy to answer specific questions from your compliance team. |
| Dashboard SAML | Not currently available. Dashboard OIDC is available on Business and Enterprise, and private-page identity providers are a separate capability. |
| Full database or disk encryption at rest | Selected dashboard OIDC secrets, OAuth tokens, and Microsoft Graph integration secrets are encrypted with AES-256-GCM, and database backups are encrypted. We do not claim blanket application-level encryption of the live database or storage volume. |
| Automatic failover and high availability | The core platform runs on a single production host in Nuremberg. A read-only database standby in Munich shortens recovery if that host's database is lost, but failover is manual, replication is asynchronous (recent transactions could be lost), the application tier is not duplicated, and a production failover has not been rehearsed. We have no automatic failover and no multi-region active-active setup. Our monitoring agents run in multiple regions. |
| Strict Content-Security-Policy | We send a Content-Security-Policy header, but it is permissive today. Tightening it is not yet done. |
| A fixed retention limit for server request logs | Request logs that include the connecting IP rotate by size; we have not configured a time-based limit. |
FAQ
Do you have SOC 2 certification?
No. We have not completed a formal SOC 2 audit and hold no SOC 2 or ISO 27001 certification. The controls we operate are described on this page. If your compliance team has a questionnaire, send it over and we’ll answer directly.
Is data encrypted at rest?
Selected dashboard OIDC client secrets, OAuth access and refresh tokens, and Microsoft Graph integration secrets are encrypted using AES-256-GCM. Passwords are irreversibly hashed with Argon2id, and database backups are encrypted before they leave the database host. We do not claim blanket application-level encryption of the live database or storage volume.
Is traffic encrypted in transit?
Yes. TLS is enforced everywhere with HSTS, including for custom domains via Let's Encrypt.
Do you support SSO?
Yes, but dashboard SSO and private-status-page access are separate features. Dashboard OIDC SSO is included on Business and Enterprise. Eligible private status pages support Microsoft Entra ID, Google Workspace, and generic OIDC for viewers. Dashboard SAML is not currently available.
How do backups and recovery work?
We run automated daily database backups. They are encrypted before they leave the database host, and an encrypted copy is kept off-site at a separate provider for 14 days; the newest two generations are also kept locally, and timestamped binary backups are taken on every deployment. Our documented recovery targets are roughly RPO 24 hours and RTO about 30 minutes, with a documented restore procedure. Replication is not a backup; the database standby is covered in the next question.
Do you have a standby database or failover?
We run an asynchronous, read-only PostgreSQL standby in a second German city, at a different provider from the primary. It shortens recovery if the primary database host is lost. Failover is manual, not automatic. Replication is asynchronous, so recent transactions could be lost, and we do not claim zero data loss. The standby covers the database tier only, there is no duplicate application stack, and a production failover has not yet been rehearsed. Replication is not a backup.
How do you protect against common web attacks?
We use CSRF protection, SSRF protections blocking private network ranges, parameterized SQL queries, server-side template escaping, security headers including a Content-Security-Policy (which is permissive today), and rate limiting on sensitive endpoints.
How can I report a vulnerability?
Email security@statuspage.me with details and repro steps. We take reports seriously and will respond as quickly as we can.
Where can I view your uptime and incidents?
Our status page is public at status.statuspage.me.
Report a vulnerability
If you discover a security vulnerability, please report it responsibly. We take every report seriously and will respond as quickly as we can.