How PulseWatch handles your data.
The short version: your telemetry never leaves your cloud account. The architecture below is designed so that's true by construction, not by policy.
- Node.js, Java, Python, .NET
- Browser RUM via Faro
- OTLP push or agent pull
- OTLP ingest, per signal
- Tail sampling
- RED metrics from 100% of spans
- Mimir — metrics, Kafka ingest
- Loki — logs, zone-aware + bloom
- Tempo — traces
- Pyroscope — profiles
Everything above runs inside your AWS or GCP account. No data crosses into PulseWatch's infrastructure.
Your VPC, always
The entire Grafana LGTM+ stack deploys inside your own AWS or GCP account. PulseWatch has no data plane that telemetry ever passes through.
Storage you control
Metrics, logs, traces, and profiles are stored in your own S3/GCS buckets, under your bucket policies and encryption keys.
Scoped operator access
The PulseWatch team holds infrastructure-configuration access for deployment and operations, provisioned through your cloud IAM, and does not hold a standing copy of your telemetry.
Standard ingestion, no lock-in
Ingestion is plain OTLP. Nothing proprietary sits between your applications and your own storage.
Compliance posture
Because telemetry stays inside your own infrastructure boundary, PulseWatch deployments are built to fit within SOC 2, HIPAA, and PCI DSS environments rather than requiring an exception for a third-party data plane. Formal certification of your own environment remains governed by your existing compliance program; PulseWatch does not itself hold telemetry that would need to be in scope.