All case studiesThe droid that reproduces customer bugs

Bug reports that arrive already reproduced.

A droid that stands between support and engineering: when a customer bug is escalated, it reproduces the issue on its own machine, captures the exact steps and logs, and files an engineer-ready issue — or, when it can’t, replies asking for the one missing detail. Engineers stop losing afternoons to “cannot reproduce,” and customers get answers faster.

Already reproduced
bugs reach engineering with steps and logs attached
No more “CNR”
the back-and-forth of “cannot reproduce” largely gone
Hours saved
per bug — the reproduction done before an engineer looks
Does
Reproduces bugs, files them ready
Where
SaaS product, ~15-person eng + support
Reaches people on
Slack, Zendesk
Works inside
Zendesk, GitHub, Linear
Runs
On every escalated bug report
The situation

Half of “the app is broken” never makes it to a bug an engineer can work.

Support escalated bugs with half the information an engineer needed, because gathering the rest — the exact steps, the environment, the logs — takes time and back-and-forth nobody had. So tickets arrived as “the app is broken,” engineers couldn’t reproduce them, and the issue bounced between teams while the customer waited.

A genuine afternoon could vanish into setting up an environment just to confirm a bug was real. What engineering needed was for every escalation to arrive already reproduced, with the steps and logs attached — and for the under-specified ones to get one good question asked, not a guess.

Isometric bug-reproduction scene: a sandbox machine with a terminal, a magnifier over a bug, a support ticket feeding in and an issue card out
How it works

How the droid took it on.

Rather than escalate half-formed tickets, the team put a droid between support and engineering. When a bug is escalated it reproduces the issue on its own machine, files it ready, and asks the customer for the one missing detail when it can’t.

TASK#377Customer bug reproductionstanding
trigger
Any bug escalated from support
also
A daily triage digest to #eng
scope
Every escalated customer bug report
runs as
A contained droid action per bug — on its own sandboxed machine
memory
Past reproductions, common environments, and known issues

Set up once, in plain language — “when support escalates a bug, reproduce it on your own machine, file it with the steps and logs, and only come to a person for a missing detail or something serious.” The droid turned that into a standing job — the bridge between support and engineering that kills “cannot reproduce.”

Every escalated bug trips the same loop:

Ongoing handling

How it ran, ticket after ticket.

Here’s a day of bug triage as it actually unfolded — across Zendesk, GitHub and its own machine. Only the one security-grade finding ever needed a person.

  1. 9:30amticket · export fails
    • Zendesk
    • Linear

    Reproduced an export timeout on a matching environment and filed ENG-3120 with logs and a hypothesis.

  2. 11:15aminfo needed · vague ticket
    • Zendesk

    Couldn't reproduce blind, so asked the customer the one unblocking question instead of escalating a guess.

  3. 1:40pmdedupe · upload crash
    • Linear
    • Zendesk

    Matched a new ticket to an existing issue and linked it instead of filing a duplicate.

  4. 2:30pmreproduce · mobile crash
    • Linear

    Reproduced a crash and pinned it to OS versions below 15, filed with the version boundary and log.

  5. 3:50pmsecurity · billing pageescalated
    • GitHub
    • Slack

    Reproducing a bug, found a request returning another tenant's data — paged the eng lead at once.

  6. 5:00pmtriage digest

    The day reconciled — 4 reproduced & filed, 1 linked, 1 awaiting info, 1 security escalated.

See it in action

One day, ticket by ticket.

Escalations from support land on the left. Watch the droid pick up each one and work it across Zendesk, GitHub and its own machine — paging a human only for the finding that warrants it.

Half our escalations used to be 'cannot reproduce,' and they'd bounce back and forth for days. Now a bug reaches us already reproduced on its own machine, with the steps, the logs, and a hypothesis attached. Engineers pick up issues that are ready to work — and the vague ones get the right question asked instead of a shrug.
Sam O.Engineering Manager, SaaS product

An illustrative workflow based on real product mechanics. Tool names and behaviour reflect how a droid actually triggers on events, runs work on its own machine, and calls connected apps; figures are directional.

Try it with your droid

Run this workflow yourself.

Copy the brief below and paste it to your droid. It’ll walk you through the prerequisites, connect what it needs, and stand the workflow up with you.

Workflow brief
I manage engineering at a ~15-person SaaS product, and support escalates bugs with half the information we need. Gathering the rest — exact steps, environment, logs — takes back-and-forth nobody has, so tickets arrive as "the app is broken," engineers can't reproduce them, and the issue bounces between teams while the customer waits. A whole afternoon can vanish just setting up an environment to confirm a bug is real.

Stand between support and engineering. Apps/channels: Zendesk (escalated support tickets), GitHub (the codebase), Linear (the engineering backlog), Slack #eng (the triage digest and paging). Use your own sandboxed machine to actually reproduce bugs.

Run on every bug escalated from support. For each one:
1. Read the ticket — the customer's environment, plan, and the exact steps they described — and pull the relevant code.
2. Spin up a matching environment on your own machine and follow the steps to reproduce it.
3. If it reproduces, capture the steps, logs, and failing path, and file an engineer-ready issue in Linear with a hypothesis; update the ticket to "reproduced, tracked."

Use judgment on what reaches a person: file the reproduced bugs ready to work, and when a ticket is too vague to reproduce, don't escalate a guess — reply to the customer asking the single most useful question. If reproducing reveals something severe — a security or data-exposure issue — page the eng lead immediately and keep details out of any customer-facing place. Post a daily triage digest. Remember past reproductions, common environments, and known issues.

What would a droid take off your desk?

Tell us the job that never gets done before close. We'll wire up a droid on a call and you can watch it work.

Try now — freeBook a walkthrough