Triage an Issue

Anectico groups similar error events into Issues. Triage the Issue, not each raw occurrence.

An explicit SDK error capture is the canonical Issue occurrence for that failure. Error-level logs linked to the capture through error.id remain searchable in Logs and stay correlated to the trace, but they do not create duplicate log_error Issues. Independent error and fatal logs without a linked capture still create Issues.

Start with impact

Open Issues and evaluate:

• how many customers are affected;
• the severity and whether the latest grouped capture was handled or unhandled;
• whether important customers or accounts are included;
• whether occurrence volume is increasing;
• the first-seen, last-seen, environment, and release; and
• whether the Issue is new or has regressed after resolution.

Use the dedicated Platform, Service, Mechanism, and Release fields to isolate one deployed workload and capture path. Each is an exact match and all four apply to the same error occurrence; a group does not match by taking its platform from one occurrence and its release from another. Applied filters remain in the page URL and in saved searches, so opening an Issue and navigating back restores the same queue. The event count, affected-customer count, first/last timestamps, ordering, and pagination are recalculated inside that exact filtered slice, not copied from the Issue’s all-release lifetime totals.

High occurrence count does not always mean high customer impact. Prefer the Issue affecting more real customers or a critical journey.

Affected-customer totals are customer totals, not raw identity totals: when Anectico has connected an anonymous identity, login identity, or another alias to the same customer, that customer counts once. In Affected customers, search by display name or any known identity alias. Search runs across the full canonical result set; use Load more to follow the returned cursor instead of assuming the first page is complete. Account badges show how many canonical affected customers belong to each account.

The account rollup is not paginated: it lists the 20 accounts with the most affected customers. The affected-account total is reported separately and counts every account, including those the list omits — so an Issue spanning more than 20 accounts is reported as such rather than as exactly 20. When accounts are withheld, Affected customers & accounts says so beneath the badges (“Showing 20 of 213 affected accounts”); when the badges are the whole rollup it says nothing.

Very large Issues are summarized rather than counted exhaustively. Anectico resolves a bounded number of affected identities per Issue, and when an Issue exceeds that bound every total on the card is shown as a floor with a trailing + — “Showing 25 of 1,000+ affected customers”. Read those as at least: the real figure is higher. A total without the + is exact.

A Person impact dashboard tile shows exact identified, anonymous, unattributed, and account totals, and its table lists only the first page of those customers — when it does, it says how many of how many. Its account badges are truncated the same way as the Issue’s and carry the same “Showing 20 of 213 affected accounts” note.

On a release detail page, the affected-person total and each account count use the same canonical identity fold, are truncated and marked the same way, and the account list says how many accounts it is not showing. New and regressed Issue rows are confined to the selected project and release, even when another project in the organization uses the same release name.

Reconstruct one occurrence

Open the Issue and choose an affected customer or recent occurrence. Follow the connected evidence:

1. compare the occurrence’s severity, handled state, capture mechanism, and application route;
2. confirm its release/distribution, SDK/platform, device model, OS, and app version/build;
3. inspect the symbolicated stack trace;
4. play the linked replay when available;
5. open the distributed trace;
6. read logs around the failing span; and
7. compare the release and rollout context.

One well-connected occurrence is often more useful than scanning hundreds of identical events.

Use Customer Detective

Ask a narrow causal question from the Issue page. Treat the result as an evidence map: follow its citations and confirm the relevant frame, span, log, or replay before changing code.

Apply a lifecycle action

Viewer access is read-only: viewers can inspect the complete Issue Story, affected customers and accounts, release context, lifecycle history, linked tickets, and previous Customer Detective investigations, but responder, ticket, and new investigation actions are not shown. Ask a member, developer, admin, or owner to operate the Issue.

• Resolve after the fix is deployed or the failure is no longer actionable. Use Resolve in next release when Anectico should reopen it only after the same Issue occurs in a strictly newer release.
• Ignore permanently when the error is expected and should not return to the active queue. Later occurrences or releases do not reopen it automatically; choose Reopen when it becomes actionable again.
• Snooze until… when action is intentionally deferred until a time, occurrence count, newly affected-user count, or escalation condition. Anectico reactivates it once when that condition is met without discarding historical occurrences.
• Assign when one current organization member owns the next step.

When a resolved-in-next-release Issue occurs in a qualifying newer release, Anectico marks it as regressed exactly once. Its Issue Story retains the resolution baseline, shows the regression release, and records the automatic transition in Lifecycle history. A clean intervening release is not blamed. Lifecycle and assignment writes use the displayed Issue revision; if another responder changed the same field first, refresh the Issue instead of silently overwriting their decision.

Link external work

After connecting GitHub, Jira, or Linear, create a provider ticket from the Issue and keep the link on the Issue rather than copying status into comments:

For GitHub, enter the target repository as exact owner/name. The repository is optional only when the active connection already has a default repository; ordinary GitHub App installations do not select one default because they may cover multiple repositories.

ISSUE_ID="grp-7f9c2a1e"
ISSUE_URL="https://app.anectico.com/issues/${ISSUE_ID}"
TICKET_CREATE_KEY="ticket.jira.grp-7f9c2a1e.v1"

anectico tickets create "$ISSUE_ID" \
  --provider jira \
  --issue-url "$ISSUE_URL" \
  --idempotency-key "$TICKET_CREATE_KEY"
anectico tickets list "$ISSUE_ID"

Copy the id returned by create or list to inspect the link with anectico tickets get <ticket-link-id>. For a timeout, interrupted connection, or other ambiguous result, retry in the same active project with the same --idempotency-key and the exact same Issue ID, title (including the default), provider, Issue URL, and GitHub repository. Anectico returns the existing link instead of filing a second provider ticket. Reusing the key with different create fields is rejected; after unlinking, use a new key only when you intentionally want a new provider ticket.

If Anectico rejects the request before contacting the provider—for example, because a GitHub repository is missing—correct the setup and submit again. That rejected attempt does not reserve the Issue’s provider-ticket slot. This differs from a timeout or interrupted provider request, where the outcome may be ambiguous and you must retry the unchanged request with the same key.

An idempotency key is a non-secret, caller-generated label: use 1–128 ASCII letters, digits, ., _, :, or -, and never put credentials, tokens, customer data, or other sensitive content in it. The Issue URL must be an absolute link to /issues/<issue-id> on your trusted Anectico dashboard origin. List/get results include the pinned connection, sync state, attempt count, last successful sync time, and a safe failure code when synchronization is waiting for a retry.

Unlinking removes the Anectico relationship but does not delete the provider ticket. Use one canonical ticket for the fix and keep investigation evidence in Anectico.

Improve future evidence

If the Issue lacks a customer, replay, readable stack, or release, fix that instrumentation gap while the failure is fresh. See Identify customers, Record session replay, and Capture errors and releases.