Know your endpoints are reachable — from where your users actually are.

How it fits together

You run one agent per environment. It receives its check schedule from the control plane, executes checks locally, and streams results to the nearest ingest endpoint over a connection it keeps open. There is no inbound firewall rule to add — the agent dials out on 443.

# /etc/pingform/agent.yaml
workspace: wk_8f3c91ba
ingest:
  endpoint: network.pingform.org:443
  transport: grpc          # grpc | websocket
  compression: gzip
checks:
  - id: api-edge
    type: http
    target: https://api.example.com/healthz
    interval: 30s
    from: [eu-central, eu-west, us-east]
    expect: { status: 200, body_contains: "ok" }
  - id: pg-primary
    type: tcp
    target: db.internal:5432
    interval: 15s
    from: [eu-central]

What teams use it for

• Regional blind spots. An endpoint that answers from your CI runner and times out from São Paulo looks healthy in every internal metric you have.
• Third-party dependencies. Payment providers and identity services degrade quietly; checks from outside their network catch it before support tickets do.
• Post-deploy verification. Pin a check to a release and fail the rollout on the first regional error budget breach.
• Contractual SLA evidence. Raw check results are exportable and retained for 13 months.

Compatible with what you already run

Results are emitted as OpenTelemetry metrics, so anything that reads OTLP reads PingForm. The agent can additionally fan out to Prometheus remote-write, Loki and generic webhooks.