# Verify your setup

> Confirm that telemetry and customer identity are connected before expanding your rollout.

Canonical page: https://anectico.com/docs/start/verify-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.

```text
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](/docs/instrument/diagnostics#verify-a-first-application).

## 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](/docs/instrument/identity).
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):

```bash
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](/docs/instrument/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](/docs/help/identity-not-linking).

## 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](/docs/instrument/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](/docs/instrument/diagnostics). It reports project-wide schema
observations separately from your person-linked journey verification.