Mojule Docs

Exporter Drift Runbook

A Telemetry Health alert means a team went silent versus its own reporting cadence. The cause is almost always exporter config drift on the customer side — an MDM rollback, an admin toggle, an egress rule — not a Mojule outage. Walk these steps in order; the alert auto-resolves once data flows again.

1. Confirm what is actually silent

Open the dashboard's Telemetry Health panel and read the per-signal dots for the silent team. The failure shape narrows the cause:

All three signals dark — the exporter is off entirely (telemetry disabled, endpoint unreachable, or token rejected). Continue with steps 2–4.
Only traces dark — the trace beta flags drifted. Jump to step 5.
One team dark, others flowing — org-level config is fine; that team's machines lost their managed settings (step 4) or sit behind a new egress rule (step 2).

2. Check the collector endpoint from an affected machine

From a machine on the silent team, verify Mojule's ingest endpoint is reachable — corporate egress allowlists fail silently:

Shell

bash

curl -i https://ingest.mojule.cloud/v1/logs -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your-mtk-token>" \
  -d '{"resourceLogs":[]}'

A 202 means network + token are fine — skip to step 4. A connection failure or timeout means an egress allowlist or proxy is blocking ingest.mojule.cloud; add it to the allowlist.

3. Verify the ingest token

A 401 from step 2 means the bearer token is invalid — most often it was rotated without re-deploying the OTEL config. In Dashboard → Connection check the token's metadata (created/rotated date). If it was rotated, re-issue the managed settings (step 4) so every machine carries the current mtk_ token. If the token may be leaked, rotate it there first — then re-issue.

4. Re-issue the Claude Code managed settings

The dashboard's Connection panel generates the current, ready-to-deploy managed-settings.json (collector URL + token + every required OTEL key). Re-download it and push it through your MDM to the affected machines:

macOS: /Library/Application Support/ClaudeCode/managed-settings.json
Linux: /etc/claude-code/managed-settings.json
Windows: C:\Program Files\ClaudeCode\managed-settings.json

MDM rollbacks and OS reimages are the most common drift source: the file is simply gone. For Claude Cowork, re-check the org Monitoring panel instead — an admin toggle there silently stops the stream.

5. Restore the trace flags (traces-only silence)

Trace spans require the beta flag AND an explicit per-signal endpoint — without either, traces silently stop while logs and metrics keep flowing:

managed-settings.json env block (trace keys)

json

{
  "CLAUDE_CODE_ENHANCED_TELEMETRY_BETA": "1",
  "OTEL_TRACES_EXPORTER": "otlp",
  "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT": "https://ingest.mojule.cloud/v1/traces"
}

6. Restore the content flags (events flow, content missing)

If events arrive but prompts show as the literal <REDACTED> and tool inputs are missing, the content toggles drifted off:

managed-settings.json env block (content keys)

json

{
  "OTEL_LOG_USER_PROMPTS": "1",
  "OTEL_LOG_TOOL_DETAILS": "1"
}

7. Confirm recovery

Have one person on the silent team run a short Claude Code session. Within a few minutes the team's signal dots flip back to flowing and the liveness alert resolves itself — no manual acknowledgement exists, by design: only data closes an alert.

Still silent after all seven steps? The remaining causes are upstream: an Anthropic-side OTEL change (the export surface is beta-labeled) or a renamed metric. Contact support with the silent team, the signal, and the alert's last-seen timestamp.