Security

Sitepulse needs a degree of access to do its job. To tell you whether your sites are healthy, we have to reach them, store the results over time, and route alerts to wherever you've asked. We treat that access as something to be earned and kept small.

The short version: we collect as little as we can, encrypt what we hold, and limit who can touch it. This page sets out how we protect your data and your account. If anything here is unclear, or you spot something we should be doing better, we want to hear about it at security@sitepulse.dev.

Most of what we store is monitoring data rather than personal data: the URLs you ask us to watch, the check results over time (response codes, response times, certificate expiry dates, DNS records, and the links we crawled), and the configuration that tells us how and when to alert you.

To run your account we also keep the basics: your email address, billing details handled by our payment provider, Stripe, and the integration settings you configure. Our privacy policy covers personal data in full.

A few things we deliberately do not do:

• We don't store your visitors' personal data. Sitepulse checks your sites from the outside. It isn't installed on them and doesn't see your traffic.
• We don't sell your data or share it with advertisers.
• We don't ask for more access to your other services than a check actually requires.

Every connection to Sitepulse, in the app, over the API, and on this site, runs over HTTPS with modern TLS, so traffic between you and us is encrypted on the wire. The database behind Sitepulse is encrypted at rest by our hosting platform.

Where we can, we connect to your other tools over OAuth rather than asking you to hand over a secret. Linking Slack or Discord authorises Sitepulse to post to the channel you pick, and we show those as a connected app rather than the underlying token. For a plain webhook you give us the URL to call, and we use it only to deliver the events you've chosen. The secrets behind these connections, such as webhook URLs and chat tokens, are encrypted before they're written to our database, and we only ever show them back to you masked, never in full.

Access to production systems is limited to the people who need it to run the service, and it's protected by strong authentication. We follow least privilege: someone can reach what their work requires and no more.

The credentials you give us for integrations are scoped as narrowly as the integration allows. A Slack or Discord connection can post alerts to the channel you choose and nothing else, and a webhook only ever receives the event payloads described in our documentation.

Sitepulse is hosted on Laravel Cloud, which runs on AWS. Our database is fully managed and backed up automatically, and each team's data is logically separated, so one account can't reach another account's sites, checks, or settings.

A Cloudflare web application firewall sits in front of the app, with DDoS mitigation, rate limiting, and bot protection on by default. Laravel Cloud is independently SOC 2 Type II certified and GDPR compliant; that covers the platform we build on rather than Sitepulse itself, but it's the foundation underneath us.

We keep our dependencies patched, watch for vulnerabilities in the libraries we build on, and apply security updates promptly when they matter.

When you sign in with a password, we store only a salted, hashed version of it, never the password itself, so it can't be read back even by us. You can update or remove your integration connections at any time from your account settings.

For an extra layer, Sitepulse supports two-factor authentication and passkeys, and we'd encourage you to turn one on. A unique, strong password and two-factor authentication on the email account tied to your login help too, since that inbox is the usual route back into any service.

Monitoring is only useful if it's running, so we monitor the scheduler and queues that run Sitepulse. Under the default issue rules, failed scheduled uptime, SSL, and DNS checks are retried after two minutes before an incident opens. Teams can change those failure thresholds, including choosing an immediate one-failure rule.

Every plan includes five check types. Each uses the probe or external service suited to the result it collects, and outbound targets are checked to prevent requests to private or otherwise blocked network addresses.

If you believe you've found a security issue in Sitepulse, please tell us before disclosing it publicly. Email security@sitepulse.devwith enough detail to reproduce it, and we'll acknowledge you, investigate, and keep you updated on the fix.

We won't pursue action against researchers who report in good faith, avoid privacy violations and service disruption, and give us reasonable time to respond before going public. A genuine thank you to everyone who does.

For how we handle personal data, see our privacy policy. If your organisation needs a data processing agreement, our DPA sets out the terms and the sub-processors we rely on. Anything that isn't covered here can go to security@sitepulse.dev, and our support team is at support@sitepulse.dev.