Security
Last updated June 19, 2026
Our security model starts with collecting less. Holter watches from the outside or via heartbeats you push — so we never hold the keys to your infrastructure.
Loose coupling by design
Holter never asks for your server logins, cloud credentials, or source code. We observe your services the way the public internet does, and for the rest your jobs ping us — so we hold far less than an agent-based tool. We minimize what we keep and protect what we do.
Data protection
All traffic is encrypted in transit (TLS). We keep what's needed to run monitoring — your account, monitor configuration and check history, alert/incident records, status-page subscriber emails, and webhook/ingest tokens. Card data is handled entirely by Stripe; webhook URLs are masked to host-only in the UI and ingest tokens are treated as secrets.
SSRF & abuse protections
Outbound checks are deliberately constrained so Holter can't be turned into a scanner: we allow only HTTP/HTTPS and TCP, reject private and internal addresses, pin connections to the resolved public IP, and don't follow redirects on sensitive fetches. Heartbeat ingest is token-gated and rate-limited.
Access & isolation
Data is scoped to your team. A monitor's ingest token is the credential for sending its heartbeats — treat it like a secret. Privilege flags (like your plan) are set server-side only.
We watch the watchman
Holter is designed to watch itself, too: our scheduler and queue can emit dead-man heartbeats to an independent, external watcher, so a stall in Holter's own systems can be caught from outside — not only from our dashboards.
Responsible disclosure
Found something? Email [email protected]. We welcome good-faith research, will respond quickly, and won't pursue researchers who act in good faith and avoid privacy violations or service disruption.