A developer working through code at a desk

For developers and engineering leads

See the customer behind the issue.

The error tells you something broke. Customer evidence helps you understand what was at stake. Bring both into the investigation, then give the team the context behind the work.

Connect your first source Inspect an example

Checkout / Investigation context

Illustrative evidence · Source relationship unverified

01 / Sentry · Error issue

PaymentTimeout

8 users affected · Checkout service

Inspect the record

An illustrative error issue reports payment requests timing out for eight users. This count describes this issue’s affected users, not the total number of abandoned checkouts.

02 / Intercom · Support conversation

“I wasn’t sure whether it had gone through.”

A customer describes waiting after submitting payment.

Inspect the record

The customer describes an unclear outcome after pressing Pay. This excerpt does not establish that they experienced the Sentry issue or identify the technical cause.

A question for the team

What happens when a payment request times out, and what does the customer see?

Before the issue reaches the sprint

Understand the impact.
Keep the diagnosis open.

Read the technical signal.

Inspect the error-related evidence and what it actually measures. Keep affected-user counts distinct from wider product impact.

Look at the customer’s task.

Read the feedback alongside the error. What was the customer trying to do, and where did the experience become unclear or blocked?

Test the relationship.

Use a focused investigation to examine explanations in the project evidence. Verify reproduction steps and the technical cause in your engineering tools.

A handoff with the reasoning attached

Give the next engineer
a useful starting point.

Send a theme to a supported issue tracker with its evidence in the body. Your team can review the context, establish reproduction steps, and agree the scope of the work.

The example shows how a team might frame the investigation. The title and investigation questions are illustrative, rather than a prescribed export format.

Explore team handoff

Illustrative issue for triage

Investigate payment timeout feedback.

Observed
PaymentTimeout affects eight users in the sample error record [1]. A customer describes uncertainty after submitting payment [2]. The records have not been linked.
Customer impact to verify
Can a customer tell whether payment succeeded, failed, or is still processing? Is retrying safe in each state?
Engineering questions
Can we reproduce the timeout? What response reaches the interface? Which logs or traces would confirm the cause?
Scope to agree
Confirm the failure mode before choosing a fix. Define the expected customer feedback and verification steps with the team.
Review source records [1] and [2]

Into your team’s workflow

Keep working where
your team works.

Linear

Beta

File a theme to a Linear team as an issue, with its evidence in the body.

Jira

Beta

File a theme to a Jira project as an issue, with its evidence in the body.

GitHub Issues

Beta

File a theme to a GitHub repository as an issue, with its evidence in the body.

View integrations and availability
Bring in the signalsInvestigate the evidenceHand over the context

Practical questions

Where adduce fits.

Does this replace our error tracker?

Your error tracker remains the place for technical diagnostics. adduce brings error signals alongside customer evidence so the team can examine the product context and decide what deserves investigation.

Can it prove an error caused the customer problem?

Related evidence can suggest a hypothesis. It does not automatically establish a shared session, customer, or cause. Inspect the records and use your engineering tools to verify the technical explanation.

Will it implement a fix or create issues automatically?

Your team owns diagnosis and implementation. The tracker workflow shown here is a user-initiated theme handoff. Configured event subscriptions are a separate workflow.

Bring customer context
into the next technical decision.

Start with the signals behind a problem your team needs to understand.

Connect your first source Working with product?