How Watari works

Settings → How Watari works holds the choices that decide when Watari acts on its own. The page shows two cards, each with the effect of the choice beside it, and one closed For engineers section for the finer settings. Each card has its own Save. Changes apply to new work only; issues already in Watari keep what was decided for them.

Owners and admins change these settings. A member who opens the page reads the two choices in plain sentences, with the names of the admins to ask.

Draft fixes on their ownCopy Anchor Link

When Watari finds an issue in your code, it can draft the fix (a pull request) straight away instead of waiting for someone to ask. Turn the switch off and Watari finds the issue in your code and waits until someone asks for a fix.

With the switch on, choose which matches Watari drafts for:

• Clear bugs only (the usual choice). Watari drafts on its own when it is sure the report is a real issue, the same line that defines a Mapped Issue. A report it is less sure about is still found in your code, and Watari asks your team one question that would settle it, on the issue and on the tracker item it came from. Your answer, typed or picked from its choices, starts the draft.
• Every issue found in your code. Watari drafts for every issue it finds in your code. You get more drafts, including for reports that turn out not to need code.

Beside the choice, Last 30 days shows how many issues Watari found in your code, how many were clear bugs, and what the choice you have selected would have done with them. It is left out when there is nothing to count yet.

Watari drafts on its own once per issue, the first time it finds the issue in your code, and never on a repository where fixes are turned off. Anyone can still ask for a fix from the issue page. This setting changes when Watari starts on its own, not what you are billed for: drafting is included with every Mapped Issue either way.

If the report arrived from a tracker (Azure Boards, GitHub Issues, Jira or Linear) and Watari does not draft on its own, its comment on the issue says it found where the problem most likely happens and that a developer can ask for a fix in Watari.

When the customer hearsCopy Anchor Link

When a fix ships, Watari writes what went wrong and how it was fixed, and posts it on the customer's ticket. With the switch on, Watari posts it on its own. With the switch off, Watari writes the update and someone on your team approves it from the issue page; Watari sends it as soon as the fix is live.

Choose when a fix counts as live:

• After your deploy (safest). Watari waits until GitHub or Azure DevOps reports the fix is live in production. A repository that has never reported a production deploy there counts the merge as live, until its first deploy is reported. You can also mark a fix as live from the issue, or reply @watariai it is live on the tracker item.
• After the merge. Only if a merge reaches your customers within minutes. If a deploy fails or stalls, the customer hears it is fixed before it is.

Deploy details (shown for After your deploy):

• Production environment name: the name your deploys report for production in GitHub or Azure DevOps, usually production, prod or live. Capital letters do not matter.
• Wait after the deploy, in minutes: 0 to 60. Gives a quick rollback time to happen before the customer hears. 0 posts right away.

Beside the card, Last customer update shows when Watari last posted one.

For engineersCopy Anchor Link

A closed section with six settings and one Save. Its heading says whether they are all on their usual values or how many were changed. Every number in the help text comes from the control beside it.

How sure the fix must be. After Watari writes a fix, it decides whether it is sure enough to open it. This is separate from Draft fixes on their own, which is about how well the report matches your code. Three steps:

• Stricter: fewer fixes open, and more issues come back to your team with a question.
• Standard (the usual choice).
• Looser: more fixes open, and more of them need a closer look in review.

Below the line, Watari does not open the fix. It asks your team one question on the issue instead, and your answer starts it again. A workspace that set its own value before these steps existed reads Your own setting until someone picks a step.

Language your engineers read. Issue titles and summaries are written in it. The customer's own words are always kept as written. Supported: English, Hindi, Spanish, German, French, Portuguese, Japanese, Korean and Chinese.

Match reports across languages. Treats reports of the same problem in different languages, such as Hindi and English, as one issue. Off by default; it adds a small extra step to every report.

Check each fix before it opens. On by default. Watari builds the change and, if it does not build, tries again, up to the number of tries you choose (1 to 5). A daily limit caps how many checks run; set it to 0 to pause checks without switching them off. The fix opens either way, with anything that did not build marked on it. Watari skips this when your own checks already run on its fixes.

Watari has its own checks for TypeScript, Python, Go and C#, and checks that a change made only of JSON files is still valid JSON. For TypeScript and C# it builds your branch first and then with the fix, so only problems the fix adds count. For every other language it runs the build your repository already uses, read from your CI definition (.github/workflows on GitHub, azure-pipelines.yml on Azure DevOps). It uses only steps it can run safely: a step that needs a secret, deploys, publishes or runs tests is left out, and Watari never guesses a command. The build runs in an isolated sandbox with no credentials. If it does not pass on your branch as it is, the check is reported as not run, never as a pass or a failure.

To set the build yourself, open Codebase, pick the repository, and fill in Build command (and an optional Setup command that installs dependencies). When set, it runs instead of Watari's own checks, in every language. Show the build from my CI shows what Watari reads from your CI and can copy it into the fields. Owners and admins can change it.

The fix always says whether it was checked, and with what. When a check could not finish it says why, and a check that did not run is never shown as passing.

Fix a failing build. On by default. When your checks fail on a fix Watari opened, Watari reads the failure and pushes one more change, at most the number of times you choose per fix (1 to 5, usually 1). It works the same on GitHub and Azure DevOps. Watari acts only when all of these hold:

• The fix is still a Watari draft.
• The change that failed is one Watari pushed, and nothing was pushed after it. Watari never builds on top of someone else's change.
• The failure is in the code: a compile error, a lint error or a failing test. A build machine, network or package-feed problem gets no change.
• The same failure has not already come back after an earlier change.

Each change is announced in a comment on the pull request. When Watari decides not to act, it posts nothing. Build results show on the issue page whether or not this setting is on.

Follow-up fixes from review comments. On by default. When a teammate asks for a change on a fix Watari opened, Watari answers with a new change within a minute or two, up to the number you choose per fix (1 to 10, usually 5). Praise and questions, such as lgtm or looks good, any thoughts on X?, are skipped. From the third follow-up, Watari also posts a note in your team chat if one is connected.

The work limit that caps Watari's monthly work is shown on Settings → Billing.

---

Next: Notifications and digest: choose which updates reach you and what the daily digest says.