Privacy-First by Design

Table of Contents

IP Address Protection

How we protect your IP address

We do not store raw IP addresses in our application database. Server request logs and a small number of older records are the exceptions, described below.

Your address is reduced before anything is written down, and how it is reduced depends on what the record is for:

• Most records are truncated. For page views, tool checks, and error logs we keep only the network part and discard the rest — 203.0.113.45 becomes 203.0.113.0. That is enough to tell one network from another; it is not enough to point at one machine. It is the same reduction mainstream analytics products apply.
• Security records use a keyed token. For audit trails and abuse prevention we need to recognise that two events came from the same source. We compute an HMAC-SHA256 token under a secret key that is not stored alongside it, so the token is meaningless to anyone who obtains only the database.
• API key activity uses a salted digest. Requests made with an API key are recorded with a secret-salted SHA-256 digest of the address; storing the raw address is switched off.
• Rate limiting never writes anything down. Blocking a flood happens in memory, in the moment, and nothing about it is persisted.
• Server request logs do include the connecting address. Our application servers keep an operational request log, in the server’s system journal, that records the IP address of each request. It is used for troubleshooting and abuse handling, is not copied into the database, and rotates automatically by size; we have not set a fixed time limit for it. Our reverse proxy does not write access logs. A small number of older database records, created before the reduction above was introduced, may still hold full addresses.

The code that does this is open source and independently auditable: hsp-ip-anonymizer. We wrote it, we publish it, and we use it ourselves.

Our Data Deletion Policy

Your data doesn’t linger forever

When you close your account, it’s immediately flagged as closed, and your data is scheduled for removal from active systems under our retention policy. The periods that apply, and how backups are treated, are set out in the Retention section of the Privacy Policy; that document, not this summary, is the authoritative statement.

What the retention policy covers

• Status pages and all related data
• Monitors and monitoring history
• Incidents and maintenance events
• Custom domain configurations
• Notification settings
• All hashed IP logs from security monitoring
• Session data and authentication tokens
• Your user account record

What we retain?

We retain billing and tax records where required, including transaction or subscription IDs, amounts, dates, billing contact details, and tax information you provide. We do not receive or store payment card data.

Cookies

Essential cookies only

We use only cookies required for authentication, security, and requested product functionality. We do not use advertising, marketing-attribution, or third-party analytics cookies. Browsing our marketing pages sets no cookie; the cookies we do set are:

user_app_session — sign-in and form protection

We create it only when it is needed for an authenticated session or a CSRF-protected form. It is:

• Set when you sign in or load a form that needs CSRF protection, such as registration, contact, waitlist, public checker, or OSS-application forms
• Cleared when you log out
• Used solely for session state and request-forgery protection
• Not used for tracking or analytics

sp_auth_… — private status pages

A status page owner can make a page private. Viewers who authenticate to that page receive a session cookie for that page only (and, while signing in with Microsoft, a short-lived sign-in handshake cookie for that page). Public status pages set no cookies.

Support widget (signed-in dashboard only):

• Sapat.chat cookies — cookies used by our first-party operated support software

Zero Tracking

We don’t track you across the web

We avoid cross-site tracking and identification technologies.

Privacy-friendly fonts

We host fonts on our own servers — no connection to Google Fonts or other third-party font services.

Cross-site tracking

We avoid technologies that follow you across different sites and do not build cross-site profiles based on your browsing.

Cohort-based tracking

We disable cohort-based tracking features such as Google FLoC via the Permissions-Policy header.

Privacy-Friendly Analytics

Plausible Community Edition — GDPR, CCPA & PECR Compliant

We use Plausible Community Edition (self-hosted) — a lightweight, open-source, privacy-first alternative to Google Analytics. We self-host it on our own infrastructure. Learn more at plausible.io/self-hosted-web-analytics or on GitHub.

You can include your web analytics in your status pages: but it must be privacy-friendly!

Data Minimization

We only collect what we absolutely need

Following GDPR’s principle of data minimization, we collect the bare minimum:

What we collect:

• Email address — For account access and essential communications
• Name — Can be your real name, alias, nickname, or anything you prefer
• Status page content — The data you choose to publish (incidents, maintenance, etc.)

What we DON’T collect:

• Home address
• Phone number
• Age, gender, race, religion
• Biometric data
• Social media profiles
• Browsing history
• Device fingerprints

Data Portability (GDPR Right)

Download your workspace data anytime

You can download a portable copy of workspace configuration and service data from account settings.

Your export includes:

• All status pages and their configurations
• Monitors and the most recent 90 days of monitoring results
• Incidents and incident updates
• Maintenance events and schedules
• Custom domain configurations

Credentials, authentication and security records, billing records, and payment-provider data are not included. Data is exported as a ZIP archive containing structured JSON/JSONL files. See how to export your data here.

Payment Security

We never see your payment details

Your credit card information never touches our servers.

All payments are handled by our payment processor, DodoPayments, which acts as the Merchant of Record. Your card data:

• Goes directly to the payment processor
• Is encrypted in transit using TLS
• Never passes through our infrastructure
• Is never stored on our servers

We retain billing and tax records where required, including transaction or subscription IDs, amounts, dates, billing contact details, and tax information you provide. Payment card data never reaches our servers.

Encryption & Security

Strong encryption for your data

We use TLS for public traffic. Selected sensitive application secrets are encrypted with AES-256-GCM, while passwords are hashed with Argon2id. This is not a claim that every database field or the full storage volume is encrypted at the application layer.

Password Security

Your password is hashed using Argon2id (a one-way password-hashing algorithm). We cannot recover your password — if you forget it, you’ll need to reset it.

Access Controls

Access to your data is restricted to authorized personnel only and logged for security auditing.

Additional Details

No Advertising

We don’t use advertising or ad-revenue services. Any links to partner services are simple hyperlinks with no tracking.

Social Media

Social media sharing buttons on our blog are hard-coded links — no 3rd-party scripts or tracking pixels.

Support Access

Support enters a customer account through Temporary Support Access: a short-lived session that you approve, that is logged, and that you can see. For urgent cases there is also an emergency access path that can start without your prior approval; 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. See how it works.

Optional Integrations

Notification channels and integrations do nothing until you enable and configure them. For example, if you enable the optional Threema notification channel and enter a Threema ID, notifications are delivered through StatusPage.me’s Threema Gateway integration using StatusPage.me’s own Gateway credentials, and the recipient Threema ID and the notification text are sent to Threema. The optional Server Agent only sends the host metrics listed in its documentation, outbound from your own servers. See Subprocessors for providers.

Live Chat

We operate Sapat.chat as first-party support software on the same owner-operated infrastructure as StatusPage.me. Its dashboard widget receives account context needed for support and uses essential cookies for functionality. Learn more in Sapat.chat’s Privacy Policy.

Data Location

We operate from Serbia 🇷🇸. Primary platform data and local backups are stored on our production server at netcup in Nuremberg, Germany 🇩🇪. Encrypted off-site backups, a read-only disaster-recovery copy of the production database, and first-party email infrastructure run on Contabo in Munich, Germany: StatusPage.me-operated Stalwart (mail.statuspage.me) processes email delivery. Brevo is used for additional delivery where applicable. Monitoring checks can execute in selected regions worldwide; monitoring nodes process the target and check configuration needed to run the check and return results centrally. Some monitoring locations are in EU member states (see the EU Monitoring Stack); that relates to where checks execute only, not to every other data flow.

Questions or data requests

If you have questions about privacy or want to exercise your data rights (such as access or deletion), contact us at hey@statuspage.me.

Who operates StatusPage.me

StatusPage.me is operated by Nikola Stojković PR Borča, a small team based in Serbia. Primary platform servers are hosted in Germany; email and distributed monitoring also use the locations described above.

Europe-focused alternative

If you want a concise overview tailored to Europe-based teams, see our European Status Page Alternative page.

Legal documents

For complete details about data processing, your rights, and legal information, please read our full Privacy Policy, Data Processing Agreement, Subprocessors and Security pages. For details on how the service is used, please refer to our Terms of Service. For how we handle requests from public authorities, see Transparency & Government Requests.