Built for reliability and compliance

Core customer data is stored in the EU and GDPR compliant by design. Uptime checks run from Germany. A non-EU region (Ashburn, USA) was retired in August 2026 and there is no active plan to bring it back.

GDPR compliant
Core customer data stays in the EU
EU probes
Uptime checks run from Germany
EU hosting
Control plane hosted in Germany
Real-time
30-second check intervals
Check flow

How a check travels through the grid

A schematic of the production dispatch path. No live traffic is shown and no endpoints are pinged by this diagram.

Control panel
Scheduler dispatch

The scheduler groups due monitors into a batch and hands each one to a worker region.

Tick every 30s
Job assigned Worker pings target Response returns to panel
EU-Central
Germany
EU-North
Finland
US-East
Ashburn
Planned
panel/app
Dispatch, ingest, evaluate, alert
panel/app dispatches check jobs, workers ping endpoints, and results return directly to the EU control plane.
How checks work in production
Job dispatch
panel/app schedules due checks and assigns jobs to available worker regions.
Endpoint probe
Workers perform HTTP and TCP checks, collecting status code, latency, and packet-loss metadata.
Result ingest
Workers send compact check results back to panel/app for rule evaluation and alerting.
Data boundary
Core customer data is stored in EU systems. Probe nodes only transmit technical check metadata.
What would leave the EU once the planned non-EU probe region is active

Today, all uptime probes run from EU regions and nothing described below currently applies. This is the data-minimization commitment for when the Ashburn (USA) probe region goes live.

  • Monitor metadata needed to execute checks: URL, method, timeout, interval, thresholds, and region assignment.
  • Configured monitor request headers (an auth header, if you set one) sent from the probe to your endpoint.
  • Check result metadata returned to panel/app: status code, latency, degraded state, and error string.
What does not leave the EU in this check flow
  • 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, meaning error events, configuration, and telemetry, is stored on EU infrastructure in Germany and Finland. Uptime monitoring currently runs exclusively from EU probe nodes; a non-EU probe node (US-East, Ashburn) is planned and, once active, would send only 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. Transactional email is the only external service that receives limited metadata.

Monitoring egress IPs

Uptime checks originate from static IPs. Use these to allowlist Unseenr in your firewall, WAF, or CDN.

RegionLocationIPv4
FSN1🇩🇪 Falkenstein, DE
178.104.80.140

WAF and firewall setup

If your endpoint sits behind a WAF or rate limiter, allowlist the IPs above so checks are not blocked.

Cloudflare WAF

  1. Open Security, WAF, Custom Rules
  2. Create a rule that skips the WAF when ip.src is in the list above
  3. Set the action to Skip or Allow
  4. Save and verify with a test check

AWS security groups

  1. Open your security group inbound rules
  2. Add one rule per IP: 178.104.80.140/32
  3. Allow HTTP (80) and HTTPS (443)
  4. Changes take effect immediately

Custom headers

  1. Every check sends User-Agent: UnseenrBot/1.0 (+https://unseenr.io)
  2. Add custom headers per monitor for authentication
  3. For example X-Monitor-Token: your-secret
  4. Configure these under monitor settings, Headers

Need help getting your WAF or firewall to let the checks through? Reach us at ···.