Bug to RCA

The fourth pipeline stage drafts a customer-facing root-cause analysis and publishes it back to the original support ticket after the fix ships.

What an RCA isCopy Anchor Link

An RCA is a customer-facing summary of what went wrong, who was affected, what caused it, what was changed to fix it, and what steps are being taken to prevent recurrence. Watari uses a consistent template so customers get the same level of detail regardless of which engineer handles the underlying fix.

The template sections are:

• Customer impact, which features were affected and for how long
• Timeline: when the issue was first reported, when the fix was merged, when it deployed
• Root cause: a plain-language explanation of the technical cause
• Fix: what was changed
• Prevention: what process or code change reduces the likelihood of recurrence

Every section is editable before publish.

When RCAs are draftedCopy Anchor Link

Watari generates an RCA draft when either of two conditions is met:

After a fix PR merges. When the Watari GitHub App detects a merge of a PR it authored for a critical or high severity bug, RCA generation is triggered automatically. For medium and low severity bugs, generation is triggered when the PR merge is detected and the cluster has reached the configured minimum size.

When a cluster grows past the threshold. If a bug's cluster (the count of linked tickets sharing the same signature) grows past the size Watari watches for, Watari triggers an RCA draft even if no PR has merged yet. This lets you communicate proactively about a known issue that is actively affecting customers.

In both cases, the draft is queued for review, never auto-published.

You are asked to update the customer once the fix is live, not before: when the deploy is confirmed, or when the fix merges if you do not wait for a deploy. The issue reads Your move · Update the customer at that moment and the notification arrives with it. If you already approved the update, Watari sends it then and nobody is asked. Approving is the send: approve it after the fix is live and it goes out right away, whether or not Watari sends updates on its own.

Deploy-aware publishCopy Anchor Link

Watari does not publish an RCA until it has confirmation that the fix is running in production. This prevents the awkward situation where a customer receives a "we've fixed this" message before the fix is actually deployed.

There are two automatic confirmation modes, set in Settings → How Watari works:

• At deploy time. Watari listens for GitHub deployment events. When a deployment for your repository reaches success status on the production environment, Watari marks the associated bug as deployed and clears the publish hold. This works for any platform that reports deployments back to GitHub: Vercel, Netlify, Render, Cloudflare Pages, and most CD platforms with a GitHub integration. The environment name is matched case-insensitively (Production and production both match).
• At merge time. If your platform doesn't report deployments to GitHub (or you run trunk-deploy where a merge to main reaches production within minutes) Watari publishes the RCA when the PR merges, with no deploy tracking.

A repository that has never reported a deploy counts the merge as live. If GitHub or Azure DevOps has never reported a successful production deploy for a repository, there is nothing for Watari to wait for, so a merge there counts as live even with At deploy time chosen: the issue moves on, the customer update is due, and the tracker item hears the fix is live. The issue page says so under The fix. The first production deploy that repository reports switches it over, and every later merge waits for its deploy.

Fallbacks cover anything the deploy event misses: an automatic periodic check that catches deploys the event missed, a manual "Mark as deployed" button on the issue page, and a reply of @watariai it is live on the tracker item the report came from (GitHub Issues, Jira and Azure Boards; on Linear, mention Watari with "it is live"). The reply works from anyone Watari trusts on that tracker, the same people who can answer its questions.

You can also configure a soak window: a number of minutes Watari waits after a successful deployment before publishing. The soak window protects against rollbacks: if a deploy lands and is rolled back within the window, Watari re-reads the deployment status after the window expires and aborts the publish.

Choose deploy or merge, and set the wait after the deploy, in How Watari works, When the customer hears.

Manual overrideCopy Anchor Link

You can publish or skip an RCA from the issue page at any time, regardless of CI status or deployment events.

• Publish now: bypasses the deployment hold and publishes immediately. Use this when you've deployed via a mechanism Watari can't detect, or when the fix is a configuration change rather than a code merge.
• Skip RCA: marks the RCA as permanently skipped for this bug. No customer reply is sent. Use this for bugs that were closed without a customer-visible fix (internal tooling, test environment issues).
• Regenerate: discards the current draft and triggers a fresh generation. Use this after editing the bug description or when the PR description changed substantially after the initial generation.

Template and editingCopy Anchor Link

The generated RCA is editable in a rich text editor on the issue page. You can change any section before publishing. Changes are saved as a new version so you can revert if needed.

The AI drafts the RCA from the PR diff, the commit messages on the fix branch, the bug description and severity, and the customer verbatims collected from the ticket cluster. The more verbatims the cluster contains, the more specific the "customer impact" section will be.

What customers seeCopy Anchor Link

The published RCA is posted where the issue came in.

From a help desk, it reaches your customer directly:

• In Zendesk, as a public comment on the ticket.
• In Intercom, as a reply in the conversation.
• In Freshdesk, as a public reply on the ticket.

When you approve an RCA you can post it as an internal note instead, if your team prefers to send the customer update itself.

From an issue tracker, it is posted as a comment on the issue Watari picked up, for your team to pass on. A tracker comment never reaches your customer on its own:

• In Azure Boards, as a comment on the work item.
• In GitHub Issues, as a comment on the issue, only when its repository is private. On a repository other people can read, it stays in Watari for your team to pass on.
• In Jira, as a comment on the issue, only when your team alone can see it. It is never posted on a Jira Service Management request.
• In Linear, as a comment on the issue, only when the issue is read only inside your workspace: not synced with GitHub or Slack, and not sent in by someone outside your workspace.

If you switched off Watari's comments on a tracker, the RCA is not posted there either. When an RCA is withheld for any of these reasons, nothing is posted and the approved text stays on the issue page, so you can copy it and send it yourself.

Who the reply comes from depends on the tool. In Zendesk, Intercom and Freshdesk it is posted through the Watari integration rather than by a named support agent, so it reads as a system or bot message depending on your configuration. In GitHub Issues and Linear it is posted as Watari. In Jira it is posted as the account that connected Jira. In Azure Boards it is posted as the user who connected Azure DevOps, or as Watari once you add Watari's service principal (see Watari as the author).

For what a good customer-facing update contains, and what to leave out, see the customer-facing RCA template.

Watari does not currently host a standalone public status page, if you want to link customers to a public URL, export the RCA markdown from the issue page and publish it to your own status page.

---

Next: Choose when you hear that a customer update is ready in Notifications and digest.