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 is

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 drafted

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 — reaches the configured threshold (set in Settings → AI knobs), 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.

Deploy-aware publish

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.

Production deploy confirmation works through your GitHub deployment webhooks. When a deployment event for your repository reaches success status on the production environment, Watari marks the associated bug as deployed and clears the publish hold on its RCA.

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.

Configure the deploy webhook and soak window in the AI behavior controls — Deploy and RCA publish settings.

Manual override

You can publish or skip an RCA from the bug detail 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 editing

The generated RCA is editable in a rich text editor on the bug detail 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 see

The published RCA is posted as a reply in the original support ticket thread:

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

The reply is posted by the Watari integration identity, not by a named support agent, so the customer sees it as a system or bot message depending on your support tool's configuration. You can edit the message template and the sender identity in Settings → Integrations.

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 bug detail page and publish it to your own status page.

Next: Configure when and how you receive RCA publish notifications in Notifications and digest — per-event toggles and daily digest settings.