No data is appearing

Work through these checks in order. Changing sampling, batching, and transport at the same time makes the failure harder to isolate.

1. Check the dashboard scope

Confirm the selected organization, project, environment, and time range. Development traffic does not appear while the environment filter is production.

2. Check the credential

• The key begins with an_ and has not been revoked.
• The key belongs to the intended organization and project.
• The application actually receives the environment variable at runtime.

Match the failing signal to its permission:

Signal	Required scope
OTLP traces, logs, metrics, and captured errors	ingest:write
Identify, group, screen, and diagnostic events sent to /api/v1/capture	analytics:write
Session replay chunks	replay:write
Feature-flag decisions from /api/v1/decide	flags:read

An SDK that sends both telemetry and identity normally needs ingest:write and analytics:write. The Ingest only access preset does not include capture, replay, or feature-flag permission.

Do not print the complete key while debugging.

3. Check the endpoint

The managed endpoint is https://api.anectico.com. OTLP HTTP exporters use /v1/traces, /v1/logs, and /v1/metrics. Diagnostic events use /api/v1/capture.

Check proxy and firewall logs for DNS, TLS, 401, 403, 413, and 429 failures.

Each rejection status tells you what to change, and they are deliberately distinct — a status that says "retry" never means "your data is wrong":

Status	Meaning	What to do
401 / 403	The credential is missing, or lacks the permission for that path	Fix the key or its access preset
400	The payload is permanently invalid, or a compressed body did not decompress	Fix the exporter; retrying the same bytes cannot help
413	The batch is larger than a single request may carry	Send smaller batches, or export more often
429	The request is throttled	Honor Retry-After when present; otherwise back off before retrying
502 / 503 / 504	A gateway, request read, or dependency is temporarily unavailable	Honor Retry-After when present; otherwise back off before retrying

For OTLP/HTTP, retry 429, 502, 503, and 504, and transient connection failures, using bounded exponential backoff with jitter. Honor Retry-After when supplied. Other 4xx and 5xx responses, including 400, 401, 403, and 413, require correction rather than retrying unchanged data. Do not resend a batch after an OTLP partial-success response: inspect its rejected-row count and error message instead. These are the OTLP retry rules; use your exporter's retry implementation rather than wrapping it in a second retry loop. This status-code list is specific to OTLP, not a retry contract for every REST or capture endpoint.

Also check the source clock. Each span, log, and metric point needs its required OTLP timestamp in the supported storage range (1900–2262); a missing timestamp (the Unix epoch sentinel) or an out-of-range timestamp rejects that row. Other valid rows continue to ingest, so one missing item beside healthy telemetry often indicates a timestamp problem rather than a batch-wide outage.

4. Force one recognizable signal

Create one manual span or captured error with a unique name. For metrics, emit anectico.verification.value=1 with check=setup, wait for the export interval, and query Last 1 hour. Avoid relying on framework auto-instrumentation until the manual signal works.

5. Flush a short-lived process

SDKs batch telemetry. Call the documented stop, shutdown, or flush method before a command, job, or test process exits.

6. Enable debug output briefly

Turn on SDK debug logging, reproduce once, and look for exporter or authentication errors. Turn it off after diagnosis.

7. Separate ingestion from identity

If the signal appears in Logs, Traces, or Issues but not in Customers, ingestion works. Continue with Customer activity is not connecting.

Metrics are normally service-scoped and do not appear as entries on a customer timeline. Do not add customer IDs as metric labels to force that connection; investigate affected customers through traces, errors, logs, and events in the same time window.

• Record application metrics
• Explore and compare metrics