Built for reliability & compliance
Core customer data is stored in the EU. GDPR compliant by design. Multi-region monitoring uses static egress IPs and can include non-EU probe regions for global uptime verification.
Visual simulation only: scheduler flow is illustrated without sending real network checks.
- Monitor metadata needed to execute checks: URL, method, timeout, interval, thresholds, region assignment.
- Configured monitor request headers (for example auth header if you set one) sent from the probe to your endpoint.
- Check result metadata returned to panel/app: status code, latency, packet-loss/degraded state, error string.
- No application event payloads or error stack traces from your product telemetry pipeline.
- No full response body storage from monitored endpoints in the uptime result payload.
EU Data Residency
Core customer data - error events, configuration, and telemetry - is stored on EU infrastructure located in Germany. Global uptime monitoring can use non-EU probe nodes (for example US-East) that only send technical check metadata back to the EU control plane.
Storage
Error payloads, attachments, and configuration are stored on encrypted infrastructure in the EU.
Database
Structured data is persisted in EU-based databases with daily automated backups.
No Third-Party Transfers
We do not sell, share, or transfer your data to third parties. Transactional emails are the only external service that receives limited metadata.
Monitoring Egress IPs
Uptime checks originate from static IPs. Use these to allowlist Errly in your firewall, WAF, or CDN.
| Region | Location | IPv4 |
|---|---|---|
| EU-Central | Germany | 91.98.5.251 |
| EU-North | Finland | 204.168.215.157 |
| US-East | Ashburn, USA | 178.156.155.91 |
WAF & Firewall Setup
If your endpoint is protected by a WAF or rate limiter, allowlist the IPs above so checks are not blocked.
Cloudflare WAF
- Go to Security → WAF → Custom Rules
- Create a rule: skip WAF when
ip.srcis in the IP list above - Set action to Skip or Allow
- Save and verify with a test check
AWS Security Groups
- Open your Security Group inbound rules
- Add one rule per IP:
91.98.5.251/32,204.168.215.157/32,178.156.155.91/32 - Allow HTTP (80) and HTTPS (443)
- Changes take effect immediately
Custom Headers
- All checks send
User-Agent: ErrlyBot/1.0 (+https://errly.app) - Add custom headers per monitor for authentication
- Example:
X-Monitor-Token: your-secret - Configure under monitor settings → Headers
Questions?
If you need help configuring your WAF or firewall to allow Errly monitoring checks, contact us at ···.