Verify your setup

Do this verification after instrumenting the first application and after any material SDK or collector configuration change.

Send a recognizable test

Use a unique customer ID and error message so you do not confuse the test with real traffic.

distinct_id: anectico-verification-user
error:       anectico verification error
environment: development

If your SDK buffers data, stop it gracefully or call its flush method before ending a short-lived test process.

Verify the first application

Get started (/get-started) checks a small, useful story before browser propagation or replay:

• A service or browser test needs an identified customer, a span with that customer's identity, and the exact named error on that trace.
• A mobile test needs an identified customer, the exact named error, and the named diagnostic event on that customer's timeline within the same time window. It checks across environments and does not verify a trace or session join.

Run the task supplied to your agent, or the manual example, then select Check my test. Paste the actual trace ID for a service/browser and select Verify customer story. This checks the last hour and links the real customer and issue only when the required evidence is found. Missing data remains unconfirmed; follow the next action and retry after processing. Re-run the test if it has aged out. Your agent can run the same check through MCP or the CLI; see Instrumentation diagnostics.

Add browser-to-backend verification

Open Check instrumentation (/configure/instrumentation) in the dashboard. In Verify your first customer story, use a controlled browser-to-backend request:

1. Configure the browser and backend with different service names (for example web and api) and the same project/environment. Enable trace propagation only to your trusted backend and allow traceparent, tracestate and baggage through its CORS policy. See Connect browser and backend.
2. Identify the test customer before the request. Send checkout_started from the browser using the same identity and session as the request.
3. Make that request produce a controlled backend exception inside its active trace. Export both the browser client span and its direct backend server child; preserve person identity across the boundary. Copy this request's trace ID.
4. When testing replay, enable it for this controlled session and wait for an upload. Otherwise clear Verify replay for this test session.
5. Enter the trace ID, customer ID, expected event, service names and environment; select Verify customer story. Choose 15 minutes, 1 hour, or 6 hours in Diagnostic time window. This selection is independent of the dashboard's global time filter.

A verified result requires an identified person, linked client/server spans carrying that person's aliases, an error on the same trace, the named event in the browser session, and, when requested, a replay session with the same session ID. It links the issue and customer for inspection. It verifies this sample's stored relationships; SDK configuration, complete delivery, replay playback and an AI explanation still need their own checks. If the profile or any required signal is missing, withheld or unavailable, the story is not verified. Retry after export/processing and follow the individual next actions. At most 200 items per required timeline signal are examined.

CLI equivalent (select the same project):

anectico doctor instrumentation --trace-id '<32-hex-trace-id>' \
  --person anectico-verification-user --event-name checkout_started \
  --browser-service web --backend-service api --environment development

The CLI expects replay by default in journey mode; use --expect-replay=false when replay is intentionally disabled. See Instrumentation diagnostics for REST, MCP and permissions.

Check the customer first

1. Select the expected project and environment.
2. Open Customers.
3. Search for anectico-verification-user.
4. Confirm the customer has recent activity.
5. Open the timeline and confirm the error and trace point to the same customer.

Finding a trace without finding the customer means ingestion works but identity is incomplete. See Customer activity is not connecting.

Check the Issue

Open Issues and search for the test error. Confirm that:

• the occurrence is grouped under one Issue;
• the affected customer is present;
• the trace link opens the expected request; and
• a replay is linked when browser replay is enabled.

Check metrics when they are part of the rollout

Emit anectico.verification.value with value 1 and label check=setup. Wait for one metric export interval, then open Signals → Metrics in the same project and environment. Select the metric, use Last 1 hour, and confirm a recent point appears.

If traces arrive but the metric does not, check whether metrics are enabled and whether the test process shut down its client or Meter Provider cleanly. See Record application metrics for SDK examples and a CLI check.

Check investigation

Ask your connected Claude Code, Codex, or CLI agent a narrow question using the test identifier. If your plan includes hosted Customer Detective (Scale), you can also ask in Investigate:

What happened to anectico-verification-user in the last hour?

The answer should cite the evidence you just inspected manually. A grounded answer with no matching evidence usually means the project, environment, or time window is wrong.

Roll out only after this passes

Once the full path works, add the next service or application. Preserve the same stable customer ID and propagate it only across trusted internal boundaries. Re-run this check after each expansion.

For a declared browser or mobile event, optionally add a pinned tracking-plan ID and revision to the instrumentation doctor. It reports project-wide schema observations separately from your person-linked journey verification.