You trust Spectate with the map of your infrastructure: your URLs and servers, credentials for checks, the phone numbers of your on-call team and the status pages your customers read during an outage. This page describes what we do today to protect that. We are a small company and do not hold certifications such as ISO 27001 or SOC 2. Questions? Email security@spectate.net.

Hosting and data location

Spectate is run by Fjordlane Holding B.V. in the Netherlands.
Your data is stored at Hetzner in Germany, in ISO 27001-certified data centres. That includes the databases, uploaded files and backups.
Our servers talk to each other over a private network. Checkers connect to our API over the internet, encrypted and with their own credentials.
Checks run from four locations, on UpCloud servers: Amsterdam, New York, Singapore and Sydney. You choose the region per monitor. Checkers outside the EU only receive the monitors that use their region, and send the results straight back to our servers in Germany.
All subprocessors and where they process data are listed on our Subprocessors page.

Encryption

In transit. The dashboard, API and status pages are only served over HTTPS. HTTP is redirected to HTTPS, and the dashboard and *.spectate.page send HSTS headers. Custom domains for status pages get their own TLS certificate automatically.
Secrets in the database. Sensitive values are encrypted by the application before they are stored: monitor settings with credentials and custom headers, notification channel settings (webhook URLs, phone numbers, tokens), Slack app tokens, alert source tokens and signing secrets, private status page access keys and two-factor secrets. Monitor passwords are never sent back to the dashboard after you save them.
Hashed, not stored. User and status page passwords are hashed with bcrypt. Host agent tokens are stored as hashes, so even we cannot read them back.

Access to your account

Verified email. You must verify your email address before you can use Spectate. Disposable email addresses are blocked.
Two-factor authentication with an authenticator app, plus recovery codes, for every user.
Sign-in with GitHub, Google or Microsoft. We only treat an email address as verified when the provider confirms it, and a sign-in provider can never take over an account with a different email address.
Roles. Every Team member has a role: owner, manager, admin, member or billing. Each role only sees and changes what it needs.
Security emails when your email address, password, two-factor settings or linked sign-in providers change.
Rate limits on sign-in, two-factor, registration and password reset. The password reset form does not reveal whether an account exists.

Application security

Protection against SSRF. Monitoring means requesting URLs that customers give us, so every connection our checkers make is checked against the IP address it resolves to, including redirects and DNS lookups. Checks cannot reach private or internal networks. The same applies to webhooks and chat integrations: their address is checked when the message is sent, the connection is pinned to that address, and redirects are not followed.
Isolated screenshots. Screenshots of failing pages are taken by a headless browser on an isolated network. Its only way out is through the checker's protected proxy.
Signed checker assignments. The API only accepts a check result with a signed, expiring assignment for that checker, monitor and region.
No secrets in snapshots. When a check fails, we store what the checker saw so you can see why. Cookies and credentials are removed from the stored headers.
Custom domains must be verified with a DNS record that belongs to one status page only, so nobody can claim a domain that still points at us.
Private status pages are never stored in shared caches. Rotating the access link or password signs out every visitor.
Error tracking runs on our own Sentry installation, configured to send no cookies, request headers or request bodies.
Development. Every change runs through automated tests and static analysis before it is deployed. Container images run as non-root users, and checkers run with a read-only file system.

Staff access

Our internal back office is only reachable from our private network, with separate staff accounts.
Every action in the back office is recorded in an audit log.
To help with a support question, staff can view the dashboard as a user. This shows a banner, logs every request, and cannot change passwords, two-factor or other security settings.
We only look at customer data when needed for support, to fix a problem or to investigate abuse.

Privacy by design

Status page views are counted without storing IP addresses, user agents or referrers.
Visitor reports on status pages store no IP address.
Subscriptions to status page updates use double opt-in.
No tracking. Our website sets no cookies and uses no analytics. See our Cookie policy.

Retention and backups

Measurements get coarser with age and are deleted on a fixed schedule, and a deleted Team is removed permanently after 7 days. Backups are kept for 14 days. The details are in our Privacy policy, section 7.

Incidents

We monitor our own platform and get alerted about errors and failed scheduled jobs.
When something is wrong on our side, we post updates on status.spectate.net.
If a security incident affects your personal data, we notify the owners of your Team within 48 hours of becoming aware of it, as set out in our Data processing agreement.

Report a vulnerability

Found a security issue? Please report it to security@spectate.net. Our Responsible disclosure policy explains the scope and the rules.

Your part

Security is shared. Turn on two-factor authentication, give team members the lowest role they need, remove people who leave, rotate alert source URLs and host tokens when they may have leaked, and set up more than one alert channel.