Use case
Most tools publish the RCA on merge. Production has not seen the change yet. Then a rollback fires and the customer has the bad version plus an apology email saying it is fixed. Watari gates the RCA on the live deploy.
A false-fixed RCA is worse than no RCA at all. The customer reads “we fixed it” and verifies, still broken. Trust is gone in one cycle. Most ticketing tools fire the customer-facing update on merge, before the build is built, before the deploy lands, before a rollback gets a chance to undo the fix.
Deploy-gated
The customer reads the RCA in production, not against your merge log. For platforms that report deployments to GitHub (Vercel, Netlify, Render, and most CD platforms), Watari holds the customer-facing update until the deploy reports success and the Compare API confirms the merge SHA is an ancestor of the live deploy. Not on merge. Not on build success. Only when the fix is provably live. (Don’t report deployments to GitHub? Switch to merge-confirmation; a periodic check and a manual confirm still keep it honest.)
deployment_status webhook
Real signal from GitHub when the production environment reports success.
Compare API check
Merge SHA must be ancestor of the live deploy SHA before the RCA unlocks.
Idempotent fan-out
sha256 version hash prevents duplicate sends to clustered tickets.
Deploy confirmed · production
deployment_status webhook fired at 10:01 UTC; RCA queued for publish.
Rollback-aware
A later deploy can quietly back the fix out, and the customer is the last one to know. Watari re-checks ancestry on every new production deploy; when the merge SHA stops being an ancestor of the live deploy, the RCA holds, engineers see a rollback banner inline in the bug view, and auto-resume fires only when a later deploy re-includes the fix.
Compare API watcher
Each new deploy re-checks ancestry of every parked merge SHA.
Rollback banner
Engineers see the rollback flagged inline in the bug detail view.
Auto-resume
When a later deploy re-includes the fix, the RCA unlocks without manual nudge.
Deploy confirmed · production
deployment_status webhook fired at 10:01 UTC; RCA queued for publish.
Multi-lingual
A trust-killing apology email reads worse in machine translation than in plain English. An extended-thinking model generates the customer-facing RCA in the language of the source ticket, resolved via IETF language tags; en-US is the fallback when no locale is detected. Internal engineering notes stay in English regardless of customer locale.
IETF tags
Language tag from the source ticket drives output language.
en-US fallback
Unknown or missing locale falls back to en-US.
Internal notes preserved
Engineering-facing context stays in English; only the customer-facing RCA translates.
Deploy confirmed · production
deployment_status webhook fired at 10:01 UTC; RCA queued for publish.
On merge is too early. The customer is reading the RCA in production. We will not publish until production agrees the fix is live.
14d
Free trial. 10 Mapped Issues. No card.
Trial policy
7d
Mismapped credit window
Billing model
0.7
Dual confidence gate
Billing model
The RCA cannot publish until the Compare API confirms the merge SHA is live, so the false-fixed case is closed at the gate. If a later rollback removes the fix from production, the bug re-opens, engineers see a rollback banner, and a follow-up RCA fires only when the fix is restored.
Every new production deploy triggers a Compare API check against every parked merge SHA. If a merge SHA is no longer an ancestor of the latest production deploy, the bug is flagged as rolled back. The parked RCA holds, the bug view shows the banner, and engineers are notified.
Yes, with an audit log. Engineers can force-publish the customer-facing RCA before the deployment_status webhook fires. The override is recorded with actor, timestamp, and reason: the gate exists by default, the override is the rare exception, and the record makes it reviewable later.
An extended-thinking model generates the customer-facing RCA in the language of the source ticket, resolved via IETF language tags. en-US is the fallback when no language is detected on the ticket. Internal engineering notes stay in English so reviewers see consistent context regardless of the customer locale.
Yes. The RCA enters a draft state when generated; engineers can edit, regenerate, or approve before the deploy gate unlocks customer delivery. Once approved, delivery is gated only on deployment_status, the edit window closes when the fix lands in production.
Connect Zendesk, Intercom, or Freshdesk, then GitHub or Azure DevOps. Tickets land mapped to the file, function, and line, ready for your reviewer to take over.
You only pay when we know what to change.