# How to investigate a customer issue you can’t reproduce

> When an export fails for a customer but works for support, compare the conditions, follow the evidence and give engineering a useful next step.

_Manav Mehra · Oct 24, 2026 · 6 min read_

![Decimal logo above Investigate what you can’t reproduce, on a warm off-white background with faint guides and halftone corners.](/blog-covers/cannot-reproduce.svg)

“The export fails for our team, but it works when your support team tests it.” An operations lead needs a report for their monthly review. Support can download a file from a test workspace, so the ticket stalls at “unable to reproduce.”

That successful test establishes what happened under support's conditions. It does not explain the customer's failure. The useful next step is to identify which conditions differ and what evidence survives from the failed attempt. You can make progress before you have a reliable reproduction.

The export ticket below is entirely fictional. Its identifiers, logs, code observations and findings are illustrative, not a customer case or an executed Decimal investigation.

## Anchor the investigation to one failed attempt

First define “fails.” Did the export button do nothing, did a job report an error, or did a completed file fail to download? Those are different points in the workflow. In this example, the customer sees an export start, then a failure message, with no file available.

Collect the account and workspace, affected user, export type and filters, exact error, and one timestamp with its time zone. Add the request or job ID if the product exposes one. Establish whether all team members are affected or only people with a particular role. Ask for this missing context together instead of sending a sequence of “try again” requests.

In Decimal, start with the conversation and ticket or account fields already available from connected sources. Keep customer reports separate from verified observations in the [investigation summary](https://docs.decimal.app/agents/investigation). If the workspace ID or failure time is missing, record the gap and request it. A connection is not a promise that every needed field is present.

## Compare the conditions, not just the button

Write down what support actually tested. “Export works” is too broad when the successful attempt used a different workspace, role or dataset. Our first comparison looks like this:

| Condition | Customer's failed attempt | Support's successful test |
| --- | --- | --- |
| Workspace | wk_example | Internal test workspace |
| User role | Analyst | Administrator |
| Export | CSV, previous month | CSV, one day |
| Included fields | Saved report with cost center | Default report fields |

Check effective permissions, workspace configuration and report settings before treating either attempt as comparable. A role label alone does not establish access to a particular report. Check relevant feature settings and versions where that information is available. Record their values at the failed attempt if you can; today's settings might differ.

For a controlled test, use an approved test workspace with representative settings and synthetic data. Match the relevant role and report definition without broadening the customer's permissions. Change one condition at a time. If you cannot recreate their configuration safely, preserve that limitation instead of describing the test as equivalent.

## Follow the failed attempt through code and logs

With a repository connected and code investigation enabled, Decimal can [search relevant files and reference code](https://docs.decimal.app/integrations/github). Ask where an export is authorized, how its selected fields reach the worker and where the failure message originates. Check the deployed revision against the code being inspected. A plausible explanation in a different version is not evidence about this request.

Use the code's actual logging fields to guide a narrow search. With log investigation enabled and [Datadog access configured](https://docs.decimal.app/integrations/datadog), Decimal can query available application logs. Start with the failed attempt's time window and workspace or request ID, then follow a job ID if the logs provide one. Preserve source links and the query's scope so another engineer can check the result.

If there is no match, check the time zone, service, index and retention before concluding nothing happened. State when the relevant logs are inaccessible or were never captured. Decimal can work with connected evidence; it does not automatically reproduce the customer session or supply missing telemetry.

## Turn the evidence into a testable hypothesis

Suppose the synthetic records show request req_example passing the export permission check at 09:42 UTC and starting job_example. At 09:43, that worker records an export failure during CSV formatting, naming the cost_center field. The inspected formatter expects a value for that field; support's successful report omitted it.

We now have evidence that this attempt reached the worker and failed during formatting. The initial permission check passed, but that does not prove every later access check passed. The field difference suggests a hypothesis: a selected field with a missing value reaches a formatter that cannot handle it. We have not established that the customer's record lacked the value, or why.

The next test is specific: hold the role, report definition and deployed version constant, then compare synthetic records with and without a cost-center value. If both pass, revise the hypothesis. If only the missing-value case fails, connect that result to the customer's request evidence before calling it the cause.

Also inspect relevant deployments and configuration changes between the last known success and first failure, if those times are known. A recent change is a candidate explanation, not proof. Look for a changed code path or setting that predicts the observed difference.

## Hand off the uncertainty with the evidence

If support cannot test the hypothesis, engineering should receive the comparison and the failed request's path, not just “unable to reproduce.” In configured escalation workflows, Decimal can carry investigation findings, source references and selected relevant attachments into an engineering issue. Review the package for unsupported conclusions and unnecessary customer data before handing it over.

For this example, the handoff says: worker formatting failure observed; cost-center handling suspected; record contents and matched test still needed. Assign the next check and keep an owner for the customer update. The outcome remains unresolved. For support leaders, that is a useful standard: every escalation should make the next investigation step clearer.

## Reusable investigation checklist

- Scope: account, workspace, affected user, impact, time zone and failed request or job.
- Comparison: expected result, exact failure and differences from the successful test.
- Evidence: available logs, source references, deployed revision and relevant settings.
- Reasoning: confirmed facts, hypothesis, contradictory evidence and access gaps.
- Next step: one discriminating test, its owner and the next customer update.

A reproduction is valuable. Until you have one, a bounded explanation of what happened, what remains unknown and how to distinguish the possibilities still moves the ticket forward.

[See Decimal's investigation workflow](https://cal.com/decimal-demo/30m)