On-Call Engineer's Guide to Reproducing a Bug from a Support Ticket

When a Zendesk or Intercom ticket escalates to engineering, the on-call developer faces an immediate problem: free-form prose, screenshots buried in a thread, and zero environment context. Watari converts that raw conversation into a Mapped Issue with structured fields, ranked code locations, and pre-parsed attachments, so the first thing you open is not the original ticket but a record built for reproduction. This post walks each step of that workflow.

Step 1: Read the Structured Fields Before Opening the Original TicketCopy Anchor Link

A Mapped Issue gives you the extraction output first: severity, repro steps, expected versus actual behavior, and customer impact, all pulled from the full conversation thread, attachments, and even voice notes. Start here, not in Zendesk.

When a ticket arrives from Zendesk or Intercom via webhook, Watari reads the subject, body, full conversation thread (in order, with author labels and timestamps), and every attachment regardless of format. Screenshots are read visually. HAR captures, stack traces, and CSVs are read as text. Voice notes are transcribed. PDFs are read page by page. By the time the ticket appears in your dashboard as a Mapped Issue, those artifacts have already been parsed into structured fields. You do not need to open the original Zendesk thread.

What to look for in the structured record:

1. Severity: signals urgency and sets expectations for how deep a repro you need before escalating further.
2. Repro steps: the extraction model normalizes these from whatever the customer wrote, including implicit steps buried mid-thread.
3. Expected vs. actual behavior: this pair is the clearest signal of what the failure boundary is. If actual behavior matches expected, the bug already closed or the repro conditions differ.
4. Customer impact: how many users or accounts are affected, and whether the failure is a hard block or a degraded experience.

One practical check: if the extracted repro steps look thin or contradictory, note that before you invest sandbox time. The retry path (covered in Step 5) exists precisely for this case.

For a precise definition of what qualifies as a Mapped Issue and how the two confidence gates work, see Concepts.

Step 2: Use Code Locations to Find the Failure Site Without GreppingCopy Anchor Link

Every Mapped Issue carries one or more code locations, each naming a file and a function, ranked by how well they match the bug. The first one tells you where to set a breakpoint or add a log line before you run anything.

Watari keeps an index of your repository and matches the structured bug against it, so the locations come from the code itself rather than from keywords in the ticket. Bug to Code explains what is indexed and how locations are chosen.

How to work the list:

• Start at the first location. Instrument it and run the repro. Most of the time this is where the failure lives.
• If it does not reproduce there, try the next locations before searching the codebase. They are ranked candidates for the same bug, often adjacent functions in the same flow.
• Treat every location as a lead to confirm, never as proof. The repro in Step 3 is what confirms it.

The practical payoff is that you skip codebase-wide grep sessions. Starting at a named function instead of a keyword search across hundreds of files is the difference between a targeted check and an afternoon of reading.

CODEOWNERS routing is relevant here too: once Watari opens a draft PR from the confirmed code location, it routes review to the owners of those specific files. If you are the on-call engineer rather than the file owner, you can use the CODEOWNERS assignment to find a colleague who knows the code better and loop them in early. See GitHub connection for how CODEOWNERS-driven routing is configured.

Step 3: Run the Repro Anchored to the Specific FunctionCopy Anchor Link

With the structured repro steps and the confirmed file and function in hand, execute the repro in a local or staging environment pointed at that function, not a general walkthrough of the feature area.

A pattern that works well here:

1. Instrument the confirmed function with a log statement or a temporary breakpoint before starting the repro.
2. Follow the extracted repro steps exactly as written in the Mapped Issue, not the original ticket prose.
3. Observe whether the instrumented function is reached and whether its behavior matches the extracted actual-versus-expected delta.
4. If the function is reached and behaves as described, the repro is confirmed. Record the environment details (runtime version, relevant config flags, data state) alongside the Mapped Issue.
5. If the function is reached but behavior diverges from the extracted description, check whether the extraction missed a state dependency. Add it to the repro steps and retry.

A code pattern for this kind of targeted instrumentation looks like the following. This is illustrative of the general approach, not a claim about Watari's internals:

// Instrument the confirmed function before running extracted repro steps
function processCheckoutTotal(cart: Cart, promoCode: string | null): number {
  console.log('[repro-trace] processCheckoutTotal called', {
    cartItemCount: cart.items.length,
    promoCode,
    timestamp: Date.now(),
  });

  // existing logic unchanged
  const base = cart.items.reduce((sum, item) => sum + item.price, 0);
  const discount = promoCode ? resolveDiscount(promoCode) : 0;
  return base - discount;
}

The key discipline: do not start writing a fix until you have confirmed the repro. A Watari draft PR is not a substitute for a confirmed repro; it is a proposed fix that needs a human to verify correctness before merge. The Code to PR doc is explicit on this point.

Step 4: Confirm or Deny the Bug Before Writing Any FixCopy Anchor Link

Confirmation is a binary outcome with two useful branches. Both are actionable.

If the repro confirms the bug, your next action is to review the draft PR Watari opened against that code location, when it drafted one. The draft PR includes the bug description, the repro steps, and the proposed diff. Your job is to evaluate the diff against the confirmed failure behavior, not to write a fix from scratch. The Code to PR pipeline doc covers how Watari iterates on the fix based on CI results and review comments.

If the repro denies the bug, there are three common explanations:

1. The bug was already fixed in the current branch but not yet deployed when the ticket arrived.
2. The repro steps have a missing prerequisite state (a specific account flag, a data condition, a third-party dependency).
3. The extraction missed context that was implicit in the customer's conversation.

In cases 2 and 3, the structured record itself is the fastest path to diagnosis. Compare the extracted repro steps against the raw conversation visible in the ticket view. If the extraction omitted something, that omission is the gap to fill.

Step 5: Feed What You Learned Back Into the FixCopy Anchor Link

Reproducing the bug usually teaches you something the ticket never said: the account flag that has to be on, the data state that triggers it, the real cause one function upstream. Put that back into the work instead of keeping it in your head.

On the issue page, Add context & retry takes a short note from you and redrafts the fix with it as guidance. Use it when:

• The repro needed a prerequisite the ticket never mentioned, and the fix should handle it.
• The draft PR targets a symptom and you found the cause somewhere else.
• The repro showed the bug only on a path the draft does not touch.

If the ticket itself is too thin to reproduce from, ask the customer for the one missing piece (the account ID, the exact sequence, the error code). Watari reads the whole thread on Zendesk, internal notes included, so the next escalation from that customer starts with more.

For every reason Watari stops short of opening a draft PR and how to unblock each, see Why a fix wasn't drafted. None of them add to your Mapped Issue count.

The Payoff: Starting at the Right FunctionCopy Anchor Link

The workflow above compresses to a single observation: reproduction is faster when you start at a named file and function rather than searching the whole codebase. The structured fields from the extraction step give you the repro steps and the failure boundary. The ranked code locations give you the instrumentation target. The pre-parsed attachments (HAR files, stack traces, voice notes) mean you never need to open the original Zendesk or Intercom thread.

For teams operating across multiple repositories, the same pipeline applies per-repo. Each Mapped Issue carries code locations from whichever repository the embedding search identifies as the best match. See plans and pricing for how multi-repository support maps to plan tiers.

The on-call engineer's job is confirmation and judgment, not search. Watari handles the search. The structured Mapped Issue, with its ranked locations and pre-parsed attachments, is the artifact that makes that division of labor work. Start with the ticket-to-bug extraction doc to understand exactly what gets pulled out of a free-form support conversation before it reaches your queue.