trust · how we run
Security at AlertPing
AlertPing encrypts everything with TLS 1.2+ in transit and AES-256 at rest, runs least-privilege infrastructure across three isolated regions, and stores only what monitoring needs. This page explains what we keep, what we never touch, and how to reach us about a vulnerability.
You point a monitoring tool at the most sensitive parts of your stack. We treat that as the core of the product, not a checkbox. If a question is not answered here, ask through the contact page and an engineer replies.
alertping ▸ security posture
- in transit
- TLS 1.2+
- at rest
- AES-256
- regions
- FRA · IAD · SIN
- alert pipeline, last quarter
- 99.99%
- disclosure ack
- ≤ 72 h
the properties
Encryption and access, by default
01 · encryption in transit
TLS 1.2 or newer, everywhere
Every connection between your browser, our API, our probe network and our alert channels runs over TLS 1.2 or newer. Plain HTTP is redirected, always.
▸ tls: 1.2+ · hsts: enforced
02 · encryption at rest
AES-256 at rest
Check configurations, contact details and response metadata live on AES-256 encrypted volumes. Backups are encrypted with separate keys.
▸ aes-256 · encrypted backups
03 · least privilege
Access on a need basis
Production access is scoped per role and granted only to the engineers who operate the system, behind multi-factor authentication.
▸ access: per-role · mfa: required
04 · audit logging
Every access is logged
Production logins and configuration changes are written to an append-only audit log we can trace end to end.
▸ audit log: append-only
05 · access reviews
Reviewed every quarter
Each quarter we review who can touch production and revoke anything unused. Access nobody needs is access nobody keeps.
▸ review cycle: quarterly
data handling
We store the check, not your users
Monitoring works from the outside, so we need very little. The full detail is in our privacy policy, but the short version fits in two lists.
what we store
- Check configurations: URLs, ports, intervals, assertion rules.
- Response metadata: status codes, latencies, verdicts per region.
- Contact emails and alert destinations you configure.
what we never store
- Your users' data. We probe your endpoints, we never see your customers.
- Page bodies. We keep only the short excerpt around a failed keyword or JSON assertion, nothing more.
infrastructure · reliability
A monitoring plane that stays up when clouds do not
Probes run from isolated monitoring regions in Frankfurt, Virginia and Singapore. Each region is a separate failure domain: the alert pipeline does not depend on any single cloud region, so an outage at one provider cannot silence the system that is supposed to tell you about outages.
We hold ourselves to the number we sell. Our alert pipeline ran 99.99% last quarter, and Enterprise contracts back that with a written SLA.
alertping ▸ monitoring plane
fra · frankfurtisolated
iad · virginiaisolated
sin · singaporeisolated
pipeline uptime q299.99%
alertping ▸ responsible disclosure
disclosure · compliance
Found something? Tell us. We will not sue you.
If you find a vulnerability, email [email protected]. We acknowledge every report within 72 hours, keep you informed as we fix it, and take no legal action against good-faith research. Please give us reasonable time to remediate before publishing.
On the compliance side: our data handling is GDPR-aligned, a DPA is available on request, and a security review with our engineers is included on the Enterprise plan, alongside SSO/SAML, roles and an audit log for your own team.
Monitoring you can point at production
Encrypted in transit and at rest, three isolated regions, and an alert pipeline that ran 99.99% last quarter.