Distributed Tracing

What it is

An OTLP ingest endpoint plus a trace browser: your applications send OpenTelemetry spans, we store them per status page and render a hierarchical span waterfall with per-service views — request-level visibility inside your own stack, where uptime checks cannot see.

Ingest keys

Traces authenticate with ingest keys — per-status-page credentials, separate from your user API tokens:

# Create a key (plaintext returned once)
curl -X POST https://api.shxrk.systems/api/v1/uptime/telemetry/keys \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{ "name": "checkout-service", "status_page_id": "<uuid>" }'
# → { "key": "sk_ingest_...", ... }

GET /telemetry/keys          # list
PUT /telemetry/keys/:id      # rename / toggle / sampling settings
DELETE /telemetry/keys/:id   # revoke

Keys are stored hashed, rate-limited per key, and can be disabled without rotating user credentials.

Sending traces

Point any OTLP-compatible exporter at the ingest endpoint with the key in X-Ingest-Key:

POST https://api.shxrk.systems/api/v1/uptime/otel/v1/traces
X-Ingest-Key: sk_ingest_...
Content-Type: application/json

OpenTelemetry Collector example:

exporters:
  otlphttp/shxrk:
    endpoint: https://api.shxrk.systems/api/v1/uptime
    headers:
      X-Ingest-Key: ${SHXRK_INGEST_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/shxrk]

Or skip the collector — most OTel SDKs can export OTLP/HTTP directly to the same endpoint.

Browsing traces

The dashboard renders the waterfall per service — span durations, errors and attributes — next to the monitors watching the same page, so an outage alert links straight into "what did that request actually do."