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.

Your agent reads your data back for you. Each check below says what to ask. If the agent shows you a link, open it: it is a read-only proof page for one person, issue or trace.

Ask your agent

"Run the instrumentation doctor for the last hour in my production project and tell me which signals are visible."

"Search for the log line 'anectico verification' and the trace with the same name in the last hour."

Job	MCP tool or action	CLI command
Check the connection, sign-in, project and ingestion	not applicable	anectico doctor
Explain why traces and logs are or are not visible	instrumentation_doctor (read action)	anectico doctor instrumentation
Search for a log line	search_logs	anectico logs query
Search for a trace	search_traces	anectico traces search
List issues	list_issues	anectico issues list
Read a metric	query_metrics	anectico metrics query <metric-name>
List captured event names	list_event_names	anectico events names
Read one customer's timeline	get_person_timeline	anectico persons timeline <customer-id>

The doctor reports visible, filtered, withheld, unavailable or unknown for each signal, and it never treats absence as proof of data loss. See Check your instrumentation. A key needs mcp:read and the read scope of each signal that it reads.

1. Check the project and environment

Confirm the organization, project, environment, and time window that your check uses. Development traffic does not appear while the check filters for production. Tell your agent the project and the environment, or pass them to the CLI command. A proof link always shows the project named in the link, whichever project you chose in the Console header.

2. Check the credential

• The key begins with an_ and has not been revoked. Ask your agent to list the keys (list_api_keys, or anectico apikey list), or look under API keys in the Console, in Agents and keys (/agents).
• 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
Browser or mobile flag decisions from /api/v1/flags/evaluate	flags:evaluate on a client delivery key
Browser or mobile survey eligibility and responses	surveys:respond on a separate client delivery key

An SDK that sends both telemetry and identity needs two separate purpose-bound keys with ingest:write and analytics:write, respectively. Native structural replay additionally needs its own replay_upload key, independent consent and current native permission. A telemetry key (purpose native_ingest) holds only ingest:write. It does not include capture, replay, or feature-flag permission. See Native intake keys.

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 and 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 ask your agent to query it over the last hour (query_metrics, or anectico metrics query anectico.verification.value --since 1h). 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 your agent finds the signal with search_logs, search_traces or list_issues, but the customer's timeline (get_person_timeline) does not contain it, 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

8. Logs missing after a pipeline change

If a native_ingest source has a transform pipeline attached, some logs going missing right after you changed it is a pipeline effect, not a transport failure — work through steps 1–6 first only if nothing is arriving at all.

• Read the source's diagnostics (GET .../pipeline/diagnostics, or anectico sources pipeline diagnostics <source-id>) for the active revision. A rising dropped count means an explicit drop step is discarding matching records on purpose — check the step's when condition. A rising refused count names a reason code (for example TRANSFORM_PARSE_FAILED when a step expected JSON or key=value text that a particular log line does not have). Neither a dropped nor a refused record is stored; their diagnostic reasons differ.
• Check the collector or exporter's own logs for the OTLP partial-success warning your library surfaces on an otherwise-200 response; its message names counts and reason codes only (never log content) and is exactly what the diagnostics read reports in aggregate.
• Preview a real sample of the log shape you expect to be affected against the active revision (POST .../pipeline/revisions/{revision}/preview, or anectico sources pipeline preview <source-id> <revision> --sample '<json>') to see precisely which step changes, drops or refuses it, without waiting for another export.
• Roll back by activating the pipeline's previous revision (or 0 to remove the pipeline entirely) if the new revision is the cause; activation is immediate to apply and drains for about fifteen seconds, not a redeploy.
• A 503 (Retry-After present) or gRPC Unavailable reporting intake pipeline unavailable is retryable and transient — nothing in that batch was admitted, so your exporter's normal retry delivers it once the pipeline is reachable again. This is not a sign that any specific record was rejected by the pipeline logic.

9. Using the Anectico collector

If the missing signal comes from the Anectico collector rather than an application SDK, read its collection health read first (GET .../collection-health, or anectico sources collection-health <source-id>) instead of working through steps 1–8: it classifies the source in one call as no signals, authentication rejected, queued, parser refusal, or verified, from stored signal counts, the collector's own queue telemetry, pipeline refusals and credential usability — so you know which of those five things to fix before checking anything else.