What's new in Watari

Upgrading gives you the new plan's limits straight away and the new price starts at your next renewal. Downgrades wait for the renewal, and a cancel or downgrade can be undone before then.

• An upgrade's Mapped Issues and repository limit apply as soon as you confirm, with nothing extra to pay for the rest of the billing period.
• A downgrade keeps your current plan until the renewal, then the lower price starts.
• Changed your mind after cancelling or scheduling a downgrade? Choose Keep on the Billing page before the period ends.

Add Watari to your Azure DevOps organization once, and pull requests, comments, reviewers and filed work items read as Watari instead of the teammate who connected it.

• Configure on the Azure DevOps card shows the steps and says when they are done, per organization
• Optional, and nothing stops working if you skip it

Overage on an invoice now never goes past the limit you chose, and every Mapped Issue counts toward one billing period only.

• With the default setting, you are never charged overage.
• Raise your limit and the charge stops at that number, even if Watari kept working for a few days after you reached it.
• Each Mapped Issue counts toward one billing period, however late a renewal is processed.

You can now change your password while signed in, from Settings, Security, without signing out or waiting for a reset email.

• Enter your current password and a new one, and you stay signed in on the device you are using.
• Any other device signed in to your account is signed out.
• If you sign in with Google, the page says so instead of asking for a password you do not have.

Watari keeps working an issue for as long as your team has something new to tell it. Add an answer or where to look, from Watari, your tracker, your help desk or your team chat, and it tries again.

• No issue runs out of attempts: whenever someone adds something new, Watari drafts again with it.
• Sending something the issue already has starts nothing, because the same inputs give the same answer. Watari says what would help instead.
• To keep costs predictable, Watari tries one issue at most five times in a day and says when it can try again.
• Draft fixes stay included in every plan and are never counted toward your Mapped Issues.

Draft pull requests and the issue page now say how sure Watari is in words you can act on: Strong, Possible or Weak, and a clear note when a fix needs a closer look.

The Watari panel in Zendesk, Freshdesk and Intercom no longer has a Mark as live button. Whether a fix reached production is for your engineers to say, so your customer is never told it is fixed on a guess.

• While a merged fix waits to reach production, the panel says it is waiting for your engineers to confirm it is live.
• Engineers confirm it from the issue in Watari, from the Slack or Teams card, or with a reply on the tracker item.
• Support still sends the customer update from the panel once the fix is live.

When Watari stops without a fix, whoever knows where to look can add the detail from the tool they work in, and everyone else sees who did it and how many tries are left.

• A support agent can add detail from the help-desk panel, an engineer from the issue tracker or Slack, and Watari tries again with it.
• Every place that offers a retry shows how many tries are left, and stops offering one when none are.
• The next update says who added detail and from where, never what they wrote, and names nobody on an issue other people can read.
• The Zendesk and Freshdesk panels update themselves while Watari works, so the agent sees the new result without reopening the ticket.

When a report may not need a code change, Watari now asks your team one question about it instead of waiting silently.

• A report Watari is unsure about gets one plain question, on the issue and on the tracker item it came from.
• Answer it in Watari, in your tracker or from Slack, and the draft fix starts with your answer.

When a Watari fix is merged in an Azure DevOps repository, Watari now drafts the customer update, just as it does for GitHub.

• Merge the draft fix in Azure Repos and the update to your customer is written from what actually changed.
• Approve it, edit it or skip it the same way you do for a fix merged on GitHub.
• Fixes that span several repositories describe every one of them, on either code host.

When an issue is ready for a fix, the Watari panel in Zendesk, Freshdesk and Intercom now has a Draft a fix button, so support can start it without opening Watari.

• An issue at Ready for a fix shows Draft a fix in the panel beside the ticket or conversation.
• One press starts the draft, the same as on the issue page and in Slack. Drafting is never billed.
• Any member of your Watari workspace can press it. The issue history names who asked, and from which help desk.

When a problem looks to be inside a stored procedure Watari cannot read, Watari stops and says so instead of drafting a workaround in the code that calls it. And when your tracker sends new issues that nothing asks Watari to pick up, you hear how many.

• A draft fix no longer patches your application around a defect that lives in a stored procedure or database function. The issue names the procedure and the next step: connect the repository that holds it, or fix it in the database.
• Stored procedures in a connected repository are now each read under their own name, so Watari can find the one an issue is about.
• Picking up issues from a tracker with no rule set? The tracker's card in Connected tools shows how many new items arrived this week and were left alone, and the owner and admins get one note every two weeks while it lasts.
• Picking up only the items your team hands to Watari is still a fine choice. The note says so, and there is nothing to change.

Every group on Issues and Home's Needs you now lists the newest first, so the issue that arrived a few minutes ago sits at the top instead of under months of older work.

• Your move (both You can do these and Waiting on your engineers), Watari's move and Done this week list newest first, by when each issue last moved.
• J and K on an issue step through issues in the same order the list shows.

When a fix is live and your customer has been updated, Watari leaves a last comment on the issue it picked up in Jira, Linear, GitHub or Azure Boards, and closes it.

• The issue your team filed no longer sits open after everything is finished. Watari says it is done, then closes it.
• Each tool closes the way your team already does: closed as completed, or moved to your Done state.
• Anything that needs a person on the way to Done, such as a required field in your Jira workflow, stays with you. Watari comments and leaves the close to you.
• Prefer to close issues yourself? Turn it off for that tool in its settings.

When Watari asks your team a question and you answer, in Watari or on the issue in your tracker, it carries on from what it already found instead of starting over.

• Watari keeps what it found and what it looked at, and spends the next try on what your answer changes.
• It never asks the same question twice, and it asks at most two questions about one issue. After that the issue goes to an engineer with what is still unknown.
• It asks only when your answer would change the fix. When every answer leads to the same change, it decides and says so.
• Questions on issues that touch more than one repository are now posted on your tracker too.

Issues that came from Zendesk, Intercom or Freshdesk now get internal notes on the original ticket as Watari picks them up, finds them, fixes them and writes the customer update, so support never has to ask engineering where things stand.

• An internal note on the ticket at each step: picked up, found in your code or a question for your team, fix in review, merged, live, and when no fix was drafted.
• Every note ends with a reply your agent can send the customer right now, worded so it never promises more than is true.
• When the customer update is ready, the note carries it word for word. Approve it in Watari and it is posted on the same ticket.
• Internal only: your customer never sees these notes. Turn them off per support tool in Settings.

When your code host has never reported a production deploy for a repository, Watari counts the merge as live, so the customer update and the tracker move on without anyone opening Watari.

• A repository that has never reported a production deploy counts its merged fixes as live, and the issue says so. The first deploy it reports switches it to waiting for deploys.
• Say it is live from your tracker: reply @watariai it is live on the issue, and Watari moves the fix on as if you had pressed Mark as deployed.
• Approving a customer update after the fix is live sends it right away, whether or not Watari sends updates on its own.
• After the merge now applies whoever sends the customer update.

Your tracker now hears when a fix is merged, and on an issue only your team can see, you can send or skip the customer update with a reply, without opening Watari.

• When a fix is merged and waiting for your deploy, the issue in your tracker says it is on its way, and Watari says again when it is live.
• When the fix is live, the comment quotes the customer update Watari wrote. Reply @watariai send to send it, send: with your own text to send your version, or skip if no update is needed.
• Watari replies with what happened, and the issue closes once the update is settled, the same as when you send it in Watari.
• The update is only shown and sent from issues your team alone can read. Anywhere else it stays in Watari.

Watari's issue cards in Slack now have buttons that do the step the card asks for: answer Watari's question, send or skip the customer update, say a fix is live, or say a fix was wrong.

• Answer Watari's question from the card: pick one of its choices or type your own, and Watari tries again with it.
• Send the customer update as written, edit it first, or skip it, after seeing the whole text and where it goes.
• Tell Watari a merged fix is live, add detail for another try, or say a draft fix was wrong and why.
• Each button acts as you, with the same role checks as in Watari, and the card then says who did what.

When Watari stops without a draft fix, or finds the code and waits, a developer can mention @watariai on the issue in your tracker with where to look, and Watari tries again with it.

• Works in Jira, Linear, GitHub Issues and Azure Boards: mention Watari in a comment with what you know, and it starts again with that detail.
• On an issue Watari found in your code but has not drafted yet, the same comment starts the first draft fix.
• Watari replies on the issue to say it is trying again, or why it cannot, so nobody has to open Watari to check.
• A mention with nothing else in it still gets where the issue stands, and every try counts against the same limit as in Watari.

Support agents see where Watari is with a ticket's issue right beside the ticket in Freshdesk, and act on it there, without opening Watari.

• The panel shows whose move it is and the next step, with the reply to send your customer now. Add it to your reply in one click.
• When the customer update is ready, send it, edit it and send your version, or skip it, from the ticket.
• Answer Watari's question from the ticket, and see when a merged fix is waiting for your engineers to confirm it is live.
• No extra sign-in. Watari matches your Freshdesk agent email to your workspace, and you can press what your Watari role allows. A Freshdesk admin installs it once; ask us for the app.

Support teammates see where Watari is with a conversation's issue in the conversation details in Intercom, and act on it there, without opening Watari.

• The panel shows whose move it is and the next step, with what to tell your customer now.
• When the customer update is ready, send it, edit it and send your version, or skip it, from the conversation.
• Answer Watari's question from the conversation, and see when a merged fix is waiting for your engineers to confirm it is live.
• No extra sign-in. Watari matches your Intercom email to your workspace, and you can press what your Watari role allows. Ask us to try it before it reaches the Intercom App Store.

Support agents see where Watari is with a ticket's issue right beside the ticket in Zendesk, and act on it there, without opening Watari.

• The panel shows whose move it is and the next step, with the reply to send your customer now. Add it to your reply in one click.
• When the customer update is ready, send it, edit it and send your version, or skip it, from the ticket.
• Answer Watari's question from the ticket, and see when a merged fix is waiting for your engineers to confirm it is live.
• No extra sign-in. Watari matches your Zendesk email to your workspace, and you can press what your Watari role allows. Ask us to try it while the app is in review.

Insights leads with three counts for the month, each beside the month before: reports that became issues, issues found in your code that got a draft fix, and fixed issues where the customer was told.

• Pick a calendar month and see it beside the month before, in plain counts such as 19 of 26.
• One next step when something is waiting on your team, such as a fixed issue whose customer has not heard yet.
• Share this month opens a one-page summary you can print, save as a PDF or forward to whoever decides.
• Months follow your own time zone, and every role sees the same page.

A new workspace now sees one setup block on Home: where your customer reports arrive, your code, and your first issue. Each step ticks when it really works, not when a form is saved.

• Step one asks where customer reports reach your team and offers every help desk and tracker Watari reads, each saying who has to sign in.
• A step only ticks when it works: the first real report arrives, your code can be searched, your first issue is in.
• When a tool has not sent anything for two days, Home says what is missing and gives you the exact steps to send to that tool's admin.
• Have a real customer ticket open right now? Add it by hand and see your first issue the same day.
• When the first issue is in, the owner and admins get one email and everyone else gets one line in Updates. Setup is then done for good.
• Teammates see who is setting up the workspace and are never asked to do it.

Settings now opens on what matters to you, shows only the choices your role can make, and names who to ask for the rest.

• Owners and admins land on Connected tools; everyone else lands on their own notifications.
• Connected tools leads each tool with whether it is working, and a tool that needs you shows one sentence and one button.
• How Watari works holds the two choices that matter, when Watari drafts a fix on its own and when your customer hears, each with what it would have done in the last 30 days.
• Billing is in three parts, your plan, this month and invoices, and the monthly limit is one choice: pause at your included count or keep going up to your plan's maximum.
• The payment card, cancelling and deleting the workspace are for the owner only, and admins see who to ask.
• Teammates see the workspace's admins by name instead of settings they cannot change.
• Settings works on a phone, from the team list to the notification switches.

Codebase now sorts every repository by whose move it is, says when it will be ready, and shows which folders your customers' problems come from and who owns them.

• Every repository reads Ready, Watari's move with the time left, or Your move with the one button that fixes it.
• If reading your code stops partway, Watari starts again on its own and only asks you when it stops a second time.
• Each repository page opens on its status. Branches, languages and files sit under For engineers, out of the way.
• Where issues come from lists the folders your issues point into, how many need you, and who owns each folder.
• Teammates who cannot change a repository see who can, instead of buttons that do nothing.
• Removing a repository keeps its issues, and what Watari learned from its code is kept for 30 days, then deleted.

Your move now shows what a support person can finish on their own before what waits on an engineer, every row names the customer's company, and every screen agrees on how many issues need you.

• Your move is split into You can do these and Waiting on your engineers, with step filters on Issues.
• Each row names the customer's company and where the report came from, plus how many other customers reported the same issue.
• Home, Issues and the sidebar show the same count of issues that need you.
• Home shows the five newest updates, leaving out issues already listed under Needs you.
• An issue can be set to Open, Won't fix or Closed, and closed issues move to Done.
• Marking a fix right or wrong can be undone for a few seconds.
• Where it happens shows the files a draft fix changes, or the strong matches, with the other places one click away.

Everything Watari sends now uses the same words as the issue page: whose move it is, the next step, and one button. Fewer messages, nothing to decode.

• Slack gets one card per issue that stays up to date, and shrinks to one line when the issue is done. Teams gets a new card only when the next step changes.
• The daily digest opens with how many issues need you, then lists each one with its next step.
• Emails and in-app updates say what happened in their first words, with one button to the issue.
• Comments on Jira, Linear, GitHub and Azure Boards open with Your move whenever a person needs to act.
• Issues Watari files carry Strong match instead of a percentage.

Settings, Codebase, Insights, Home and the issue pages now use the same plain words, so a support lead reads one story wherever they look.

• Code matches read Strong, Possible or Weak match on Codebase hotspots too, with the number one hover away.
• Settings, connected tools and the team roles card describe what Watari does in everyday words.
• An alert about a connection opens connected tools, and an alert about one issue opens that issue.
• The Found in your code count on Insights only counts issues Watari actually found in your code.

Home, Issues and every issue page now lead with the one thing that needs doing and who does it, in plain words a support lead can act on without reading code.

• Each issue page opens on one next step, marked Your move or Watari's move, with a reply your team can send the customer meanwhile.
• Issues is sorted into Your move, Watari's move and Done this week, and every row says what the issue page says.
• Home shows what needs you, what Watari is working on, and every update, in one place.
• Likely places in your code read Strong, Possible or Weak match instead of a percentage.

Keep your code in one Azure DevOps organization and your work items in another: one Watari workspace now connects both with a single Microsoft sign-in.

• Tick every organization you need when you connect, or add one later from the Azure Boards settings.
• Repositories, draft pull requests and work item pickup each work in whichever organization they live in.
• Remove one organization without touching the others.

Protocol v7 scores 105 pre-registered cases across seven repositories we had never touched, all out of sample: the top-ranked file was right in 80 of 92, against 67 of 107 in the previous run.

Every issue Watari files in Jira, Linear, GitHub Issues or Azure Boards now lists the likely files and functions behind the bug when Watari is confident about them, so whoever picks it up, a person or a coding agent, starts in the right place.

• Up to three likely code locations, each with the file, the function, the lines and the repository, in the order Watari ranked them.
• Only locations Watari is confident about. Less certain ones stay in Watari, so nobody is sent down the wrong path.
• Assign the issue to the coding agent you already use and it has the problem, the steps to reproduce and where to look.
• On a public GitHub repository or Azure DevOps project, the code locations stay in Watari along with the customer's own words.

Teams that log customer problems in Azure Boards, Jira, Linear or GitHub Issues rather than a help desk can hand the item to Watari where it already lives, and it comes back located in your code with a draft pull request.

• Azure Boards joins Jira, Linear and GitHub Issues. Mention @watariai on a work item, assign it to an identity you choose, or pick up new work items by type, state, tag or area path.
• Mentions cost nothing. Assigning work items to a dedicated user is optional, and can take a paid Azure DevOps seat.
• Watari comments on the work item when it has triaged it and when a draft pull request opens, and links a pull request in Azure Repos to the work item so each shows the other.
• When the fix ships and your team approves the customer-facing summary, it is posted on the work item for whoever filed it to pass on.
• Off until an owner or admin turns it on, and only the projects you choose are read. Switching it on never pulls in your backlog.
• An item picked up from a tracker is billed exactly like a support ticket, only when it becomes a Mapped Issue. Progress comments are included.

A ticket sent while a repository is still indexing is now mapped to code as soon as the index is ready, and the setup checklist stays open until tickets can actually reach Watari.

If your team tracks customer problems as GitHub issues, hand one to Watari with a label or a mention and it is triaged, located in your code and drafted as a pull request, with progress posted back on the issue.

• Hand an issue over the way your team already works: add a label, mention @watariai in the description or a comment, or pick up every new issue in the repositories you choose.
• Off until you turn it on, and you choose the repositories. Switching it on never pulls in your backlog.
• Safe on public repositories: only people with write access can hand an issue to Watari, and anything skipped is listed with the reason.
• Progress shows up on the issue itself, and the draft pull request points back at the issue it came from. Merging never closes your issue for you.
• On a repository that is not private, Watari's comments carry the status and a link only. Nothing about your code or your customers is posted where the public can read it.
• One report, one issue: Watari does not file a second issue beside the one you gave it.

If your team tracks customer problems as Jira issues, Watari now reads them like support tickets: label, mention or assign an issue and it is triaged, located in your code and drafted as a pull request, with progress posted back on the issue.

• Hand an issue to Watari with a mention or an assignment, or let it pick issues up by rule. Choose every new issue in the projects you pick, and nothing already in your backlog is pulled in. Or choose an issue type, a status, a label or a component, and an issue is picked up when it is created or next edited while it matches.
• It is off until an owner or admin turns it on, and Watari reads only the projects you tick.
• Works with both ways of connecting Jira. Connected with Continue with Atlassian, Watari sets up the delivery for you, with no Jira administrator; with an API token that is not an administrator's, the settings show a Jira administrator exactly what to add, once.
• Watari comments on the issue when it has triaged it and when a draft pull request opens, and adds the pull request to the issue as a web link.
• On Jira Service Management projects, a request or comment from a portal customer never starts work by itself. Someone on your team hands it over, and Watari's notes there stay internal.
• An issue picked up from Jira is never filed back into Jira as a second issue, and issues Watari filed are never picked up as new reports.

If your team tracks customer problems as Linear issues, Watari now works from them directly: delegate an issue to Watari or mention it, and the issue is triaged, located in your code and drafted as a pull request, with progress posted back on the issue.

• Watari sits in Linear's assignee menu. Delegate an issue to it, or mention it in a comment, and it answers on the issue within seconds and gets to work. It does not use a paid Linear seat.
• Or let it pick issues up by rule. Choose every new issue in the teams you pick, and nothing already in your backlog is pulled in. Or choose a status, a label or a project, and an issue is picked up when it is created or next edited while it matches.
• It is off until an owner or admin turns it on, and Watari reads only the teams you tick. Issues anywhere else are discarded on arrival. An issue sent in from outside your workspace waits for someone on your team to hand it over.
• Watari comments under its own name when it has triaged the issue and when a draft pull request opens, and attaches the pull request to the issue, whether your code is on GitHub or Azure Repos.
• An issue picked up from Linear is never filed back into Linear as a second issue, and issues Watari filed are never picked up as new reports.
• Issue filing to Linear works as before with no change on your side, and reconnecting Linear now keeps the team you chose.

A ticket you add yourself can now carry the screenshot, recording or log that came with the report, and Watari reads them like any other attachment.

• Attach up to five files to a ticket you add by hand: screenshots, screen recordings, audio, logs, PDFs and documents.
• Three optional fields, where it happened, what should have happened and the steps, for when you know them.
• The Issues list shows each ticket's source with that tool's own mark, including tickets added by hand.

Insights now has a printable summary of what Watari did with your customer reports, and the workspace owner receives it once by email.

Watari now opens a draft pull request on its own only when it is confident the report is a real issue. Anything less sure is located in your code and waits for one click.

Protocol v6 scores 120 pre-registered cases across eight repositories we had never touched, all out of sample: the top-ranked file was right in 67 of 107.

Before Watari pushes a draft PR, it now runs the build your repository already uses, so Java, Kotlin, Rust, Ruby and every other language get the same check TypeScript, Python, Go and C# had. A draft nothing could check says so on the PR.

• Watari reads your build from your CI definition (GitHub Actions or Azure Pipelines) and runs it in an isolated sandbox. When a fix breaks your build, Watari sees the errors and tries again before your team sees the PR.
• Prefer to say it yourself? Add a build command, and an optional setup command, in the repository's settings. It is used instead of Watari's built-in checks.
• Every draft PR now has a Validation section that says what was checked. When nothing could be checked, it says the draft is not validated and how to change that.
• Your CI still comes first: where your pipeline already builds Watari's pull requests, its result is the check.

When your CI fails on a draft PR Watari opened, Watari reads the error and pushes a fix commit to that branch, on GitHub and Azure DevOps alike. On by default.

• A draft PR your team opens should already build. When a compiler error, lint error or failing test shows up on a Watari draft, Watari pushes one follow-up commit that fixes it and says so in a comment on the PR.
• It only touches its own work: Watari fixes a failure on a commit it pushed itself and never builds on top of anyone else's. If someone pushes while Watari is working, nothing is written.
• It only acts on code: a package feed, network or build agent problem gets no commit, and a failure it already tried to fix is not tried again.
• The same behaviour on GitHub and Azure DevOps. Turn it off or allow up to five fix commits per PR in Settings, How Watari works, For engineers.

The billed unit is renamed Mapped Issue, because a code-actionable feature request now counts the same as a bug. Tickets and Requests are one Issues list with a type switch.

• The unit you are billed for is called a Mapped Issue: a bug, or a code-actionable feature request (a specific change to code you already have), paired with the file and function Watari ranks as the most likely cause. Nothing about your bill changes with the name.
• An open-ended feature request, and any question, is never mapped and never billed. It is still filed to your issue tracker.
• Tracker sync is never billed. Filing to Jira, Linear, GitHub Issues or Azure Boards stays bundled, whatever those tools call the record they create.
• The sidebar used to carry Tickets and Requests as two entries pointing at the same list. They are now one Issues entry with a Bugs / Requests / All switch on the page itself, the way Linear, Jira and GitHub all shape it.
• The list moved from /tickets to /issues so the address bar matches what the product calls it. An old /tickets link no longer resolves. The meter doc is now /docs/billing/mapped-issue-meter, and the old doc URL redirects.

A draft fix can now land in the file that actually carries the defect, even when it is not one Watari first mapped the bug to.

• Near-miss mappings no longer end in no fix
• Read-only and bounded, it never writes anything outside the pull request it opens for you

HTML, Handlebars and Go templates, PostCSS, and dependency manifests like package.json and go.mod are now indexed, so a bug whose fix edits one of them can be mapped to it.

Protocol v4 scores 120 pre-registered cases across eight new repositories, every one of them out of sample, and reproduces the previous result rather than improving on it.

The embedding phase reports queue position and an estimated finish time instead of showing a spinner that could not distinguish waiting from stuck.

Running Connect again on GitHub or Azure DevOps keeps everything else you had set on that integration, including the Azure event channel, and a one-click repair restores event delivery.

Each language in a repository is labelled parsed, text-chunked or not indexed, and documentation no longer triggers a coverage warning it was never a shortfall in.

Integrations that are connected but have never received a single ticket are flagged in Settings, with the setup step that is usually missing.

Watari now points at the file the merged fix actually changed in 36 of 56 benchmark cases, 64.3%, with a 95% interval of 51.2% to 75.5%. The first published run scored 8 of 17, 47.1%, on a smaller sample.

• Nothing to configure. Every connected repository picks this up the next time it is indexed.
• The number and every case behind it are at [/proof](/proof), including what got worse: repository routing went from 56 of 56 to 55 of 56. The change was chosen by looking at these same cases, so read it as a ceiling rather than as evidence it generalizes.

A pre-registered measurement of how often Watari reads a bug report and points at the file that actually had to change, with the protocol, the frozen sample and the unedited results in a public repository.

• Ground truth is the maintainer's own merged fix on public issues from six open-source projects in six languages, so a third party produced the answers before we ran anything.
• The protocol was committed before the sample was frozen, and the sample before the results. That ordering is checkable with git log in the public repository, not something you have to take on trust.
• Every case is published, hits and misses alike, with the file Watari chose next to the file the maintainer changed. Every rate carries its denominator and its confidence interval.
• It measures one step of six. It says nothing about whether the draft pull request is any good or whether the customer-facing incident report reads well, and we do not put a number on those.
• Read it at [/proof](/proof).

When build validation fails on a Watari draft, the failure is read with the file and line that failed and the fix is revised. A pull request merged outside the app is reconciled back to the bug it resolves.

Repositories and notifications belong to the workspace you have open, so each workspace shows its own data and archiving in one leaves the others untouched.

Files over the old size ceiling are now chunked and searchable, so a bug whose cause lives in a big legacy file can still be mapped.

Large monorepos index and embed to completion, and a repository that cannot finish raises a notification instead of sitting in progress.

Tighter write permissions for workspace members, stronger multi-factor enforcement, and stricter verification of inbound code-host events.

A second Jira connect path using an Atlassian API token, plus alerts when a tracker stops accepting what Watari files.

• Jira sites that require admin approval before an app can be installed can now be connected with an Atlassian account email and API token instead, which sits under a different admin policy. Credentials only ever go to your Atlassian Cloud site.
• A Jira project without a Bug issue type (team-managed Scrum projects have none) no longer rejects every filing: the issue type is chosen from the project's own schema.
• If a destination stops accepting issues, whether the site was deleted, the project is gone or the credentials were revoked, the integration is marked disconnected and you get told once, rather than silently failing on every bug.

Filing can be turned off per integration, so you can have your codebase indexed and pull requests drafted while nothing is ever opened in your issue tracker.

The full conversation is read rather than the latest reply, reconnecting a support tool keeps your configuration, and each provider account keeps its own tickets distinct.

Watari now reads whatever your customer sent: PDFs, screen recordings, voice notes, logs, HAR captures, CSVs and Office documents, not only images.

• Screenshots and screen recordings are read visually, and a recording's narration is transcribed too. The clearest description of a bug is often something the customer said out loud while reproducing it.
• PDFs are read page by page, including scans with no text layer, so an invoice or an exported report attached to a ticket is evidence rather than a download link.
• Logs, HAR captures, stack traces, CSVs and Office documents are read as text and quoted verbatim into the bug report, so the exact error your customer hit is right there.
• Files attached anywhere in the conversation are read, not only those on the latest reply, on Zendesk and Freshdesk alike.
• Archives are still stored for download and deliberately not opened.

Azure DevOps (Azure Repos) joins GitHub as a supported code host, the full ticket-to-draft-PR pipeline now runs on Azure DevOps at parity with GitHub.

• Connect Azure Repos in Settings → Connected tools through Microsoft Entra ID: tenant-backed OAuth with short-lived, admin-revocable tokens, not a personal access token. Pick your organization, project, and repository.
• Full pipeline parity with GitHub: index the repo, map each bug to the responsible file and function, open a draft pull request, watch build validation, and hold the customer-facing RCA until an Azure Pipelines production stage confirms the deploy.
• Your branch policies run untouched: Watari publishes the draft so build validation and required reviewers apply exactly as they would on a human-opened PR. Watari never bypasses a policy.
• Optionally add Watari's service principal to your organization to have pull requests authored by "Watari" instead of the connecting user, the way Renovate and Copilot operate on Azure. Skip it and PRs are simply human-authored; nothing depends on it.
• Mix GitHub and Azure DevOps repositories in one workspace, a bug is routed to whichever repositories its code actually lives in, regardless of provider.

Per-bug status-change emails are now opt-in and off by default, so your inbox stays quiet unless you ask for them.

The customer-facing RCA reply now reads in Watari's own first-party voice, with no AI hedging and no vendor names exposed.

Auto-generated PRs now edit large files reliably: the change lands where it belongs and the rest of the file stays intact.

A production-readiness pass that makes billing, recovery, and dashboard numbers trustworthy under real-world failure.

• Billing is retry-safe end to end, so a redelivered event can never double-bill you.
• Repositories and bugs that stall mid-run are recovered automatically instead of being left stuck.
• One flaky third-party service can no longer cascade into the rest of the pipeline.
• Dashboard metrics show real deltas: placeholder and estimated numbers were removed.

Freshdesk joins Zendesk and Intercom as a supported support tool, escalated tickets flow into the same ticket-to-draft-PR pipeline.

• Connect in Settings → Connected tools by pasting your Freshdesk domain and API key, validated live against your account.
• Inbound tickets arrive over a per-tenant verified webhook you wire into one Freshdesk Automation Rule, so only escalated tickets reach Watari.
• The API key is AES-256-GCM encrypted at rest and tenant-isolated by row-level security, like every other integration.
• The customer-facing RCA is published back as a public reply on the originating Freshdesk ticket once the fix ships.

File mapped bugs into GitHub Issues alongside Linear and Jira, an explicit, opt-in destination you choose per workspace.

• Pick the destination repository explicitly, like Linear and Jira; it's off until you turn it on.
• Only bugs that clear the Mapped-Bug confidence bar are filed, and each can route to the repo it actually maps to.
• Fixes the old behavior of filing into the oldest-connected repo for multi-repo workspaces.

Connect more repositories as you grow, and let a single bug fan out into coordinated draft PRs across every repo it touches.

• Repo count scales with your plan; Growth and above unlock cross-repo PR fan-out.
• One bug that spans several repos opens a coordinated draft PR in each, routed to the right reviewers.
• Downgrades deactivate excess repos instead of deleting them, with an in-app chooser for which to keep; upgrading reactivates them.

Teammates with a matching company email domain are offered "Request to join" your workspace instead of creating a separate silo, with owner approval.

A GitHub installation now maps to exactly one workspace, and you can connect an App you've already installed instead of dead-ending on GitHub's configure screen.

Notifications are calm by default and scoped to what's yours, plus watch and subscribe so you follow the specific bugs you care about.

• Bug alerts go to the assignee first instead of blasting the whole team.
• Watch or subscribe to individual bugs to follow only what matters to you.
• Bulk emails carry one-click, standards-based unsubscribe.

A re-wired onboarding checklist on Home, clearer indexing wait times, and a gentle nudge if setup stalls.

The Tickets list now shows the client company on each row, and the detail view surfaces who's affected and how widely.

• A Customer column replaces the old quote snippet on the Tickets list.
• The ticket detail shows structured company information and the cluster's blast radius.

The draft-PR pipeline now rides out slow responses, GitHub blips, and stalled runs instead of failing the whole run.

• Trouble on one workspace's GitHub connection no longer affects anyone else's.
• Busy periods slow drafting down instead of failing it.
• Failed drafts can retry immediately instead of waiting out a lock.

Bugs now route to the repositories whose code actually matches, so the right repository is found even when you have many.

• A bug goes to the repositories where its code actually lives.
• Draft PRs open in exactly the repositories the fix touches.
• Each mapped location shows a source-repo badge, and re-mapping takes your hints into account.

Send feedback and attachments straight from the Help menu; the team triages it in an internal board.

Big repositories now index without running out of memory, with live progress.

• Indexing stays stable however large the repository is.
• Repos up to tens of thousands of files index cleanly; larger ones are flagged gracefully instead of failing silently.
• Watch indexing progress live, with automatic recovery if a run stalls.

A calmer, faster workspace: a borderless sidebar on a paper canvas, one floating content card, and a real Inbox.

• A dedicated Inbox route replaces the old notification bell.
• A sidebar search row opens the ⌘K command palette from anywhere.
• Settings moved into the profile menu, and a Help launcher sits in the footer.

The pipeline keeps only vector embeddings and structural metadata, your actual source is fetched on demand and discarded.

• Source file contents are no longer persisted. The only code text kept is a few-line preview per mapped code location, shown on the issue.
• When code is needed to map a bug or draft a fix, it's fetched from GitHub at the indexed commit and thrown away.
• Tokens and secrets stay AES-256-GCM encrypted, and tenant data stays isolated by row-level security.

A public blog with practical playbooks on turning support tickets into shipped fixes and customer-facing RCAs.

A full product documentation site launched at /docs, covering setup, the pipeline, settings, and billing.

A rebuilt marketing site, complete legal coverage, and hardened sign-in landed together.

• A product-tour homepage and use-case pages.
• Full legal coverage: privacy, terms, DPA, subprocessors, and acceptable-use.
• Two-factor authentication, bot protection, and email confirmation on sign-up.

A new name and brand across every customer-facing surface.

Generated fixes are type-checked in a sandbox before the PR is drafted, catching hallucinated code before it reaches your review.

Watari extracts bugs from tickets in any language and publishes the RCA back in the customer's original language.

• Customer verbatims are preserved untouched, including mixed languages like Hinglish or Spanglish.
• Screenshots and short screen-share clips are read by a vision-aware model.

Fixes that span several repositories fan out into coordinated per-repo draft PRs, with the RCA gated on all of them merging.

Every Watari-drafted PR shows the same green/red CI signal GitHub does, mirrored into the dashboard and Slack.

• Reads the check and status events your branch protection already trusts, no new CI integration.
• The PR tab shows passing, running, or failing with a per-check breakdown.
• The Slack notification carries a live CI line that updates in place and pages reviewers on the first failure.

Leave a review comment on a Watari-drafted PR and it proposes the follow-up commit on the same branch within minutes.

• A classifier reads each comment, and only actionable feedback triggers a regeneration.
• Follow-ups are committed to the same branch: no force push, no history rewrite.
• A per-workspace iteration cap, with a Slack heads-up if the fix isn't converging.

The same issue reported by many customers clusters into a single canonical bug, one fix, one RCA fanned out to every linked ticket.

• Incoming bugs are embedded and deduplicated across all your support tools plus email.
• You're billed per fix, not per duplicate report.
• When a cluster grows, Watari pings the thread so you see the blast radius.

When a repository has no CODEOWNERS file, Watari infers likely owners from commit history and can open a one-click PR to add it.

Pay only for Mapped Bugs (a bug paired with the exact file and function responsible) with PR drafts, RCAs, and tracker sync bundled in.

• A bug is billable only when both extraction and code-mapping clear a confidence bar, and each one is billed once.
• PR drafting, customer RCAs, and Slack, Linear, Jira, and GitHub sync are bundled, never metered.
• Billed in INR for India (with GSTIN) or USD elsewhere, with GST-compliant invoices and a seven-day mismapped-credit window.

Watari writes a root-cause analysis back to the original ticket, but only after the fix actually reaches production.

• The RCA publishes on a confirmed production deploy, not just on merge.
• A later rollback parks the RCA and warns engineers.
• It's published in the customer's own language, back on the ticket where they reported it.

Draft PRs are routed to the right reviewers by reading your CODEOWNERS, with branch-protection awareness.

• Existing CODEOWNERS rules drive reviewer assignment automatically.
• Set the PR target branch per repository or per PR.

Connecting Zendesk is now one click: Watari auto-provisions the webhook and a per-tenant signing secret, with no manual setup.

Watari now turns real support tickets into structured bugs, Zendesk tickets and Intercom conversations flow in by webhook.

• Scope what reaches Watari with a Zendesk trigger tag or an Intercom team assignment.
• Each ticket is normalized and structured against a strict schema: severity, repro steps, impact, and the customer's own words.
• Non-bug tickets like billing and account questions are classified and skipped.

New ways to navigate: a Code Hotspots page, a ⌘K command palette wired to live data, and a ticket view split into Customer, Engineering, Reasoning, and Metrics lenses.

GST-compliant PDF invoices (CGST/SGST and two-zone USD), an upcoming-invoice card, and a monthly or annual billing toggle.

A realtime in-app notification center plus a full transactional email system (welcome, invites, bug and status alerts, billing, and digests) built to render correctly in Gmail.

Watari writes the fix and the test, checks them, and opens a draft PR, the core support-ticket-to-PR loop.

• Watari drafts the patch plus a test, and validates both before the PR opens.
• The draft PR lands in your repository with live status in the PR tab.
• Slack notifies you when the PR is created and when it merges.

Each extracted bug is mapped to the specific files and functions responsible, with a confidence score, shown in a Code tab.

• Vector search plus a confidence-scored rerank narrow to a file-and-function pair.
• Bugs that span multiple repositories route to the right one.

Watari pulls key frames from screen-share videos attached to tickets and embeds them into the bug and any Jira or Linear issue.

Install the GitHub App, pick repositories, and Watari indexes them so bugs can be mapped to real code.

• Parsing plus embeddings build a high-recall index across more than twenty languages.
• A file browser and per-repo detail page, with re-index on demand.
• Push webhooks keep the index current as your default branch moves.

Watari now extracts both bugs and feature requests from support tickets, and files each one appropriately.

• Feature requests create Jira Stories (bugs stay Bug type) and carry a Feature Request label in Linear.
• A dedicated Requests view and a type filter keep triage clean.

The first release: a multi-tenant SaaS foundation with the dashboard, notification delivery, billing, and team management the rest of the product builds on.

• Multi-tenant workspaces with role-based access and team management.
• Delivery to Slack, Linear, and Jira.
• Razorpay billing with a free trial.
• The dashboard shell, authentication, and onboarding.