Regression Detection After a Deploy: Issues for New Failures in Production

Last verified on Nov 10, 2026.

What a regression is

A regression is something that worked before a change and fails after it. The change might be a deploy, a configuration edit, a dependency bump or a migration. In production it often shows up first as a message nobody has seen, a latency jump or a model that suddenly answers differently.

Sazabi covers these with four live signals. No alert rules are involved: the Sazabi agent sets up sensors for your project, maintains them as your system changes, and investigates when one fires.

What feeds this category

• Novel event opens an issue when a new kind of error appears in your logs. It comes from new-error detection. Details are on the new error detection page.
• Latency step change fires on a sudden jump in latency.
• Post-deploy shift is any other signal that starts within minutes of a deploy, tied to the commit.
• LLM behavior drift fires when model outputs change in length, refusals, malformed JSON or token use, which is how a prompt or model-version change tends to show.

The browser half of a bad release, with exceptions and failed fetches, is covered under frontend breakage.

Example: a migration changes a column

This is an example, not output from a real project. A Friday release renames a database column. Within minutes a service starts writing:

2026-11-08T16:21:07Z ERROR invoices-worker generate_pdf failed: column "tax_region" does not exist (invoice_id=88213)

Your logs have never contained that message, so Novel event opens an issue with a name along the lines of "Invoice PDF generation failing on missing tax_region column". If the same release also made checkout much slower, the Latency step change sensor fires too. The agent checks whether the timing lines up with the deploy and says so in the issue.

What you see in Sazabi

An issue arrives already investigated: name, description, severity from low to critical, optional component, status, and the agent's analysis and evidence. Three details matter after a bad deploy:

• A repeat of the same problem folds into the open issue, so a flood of one error does not bury the inbox.
• If you resolve the issue and the problem returns, Sazabi opens a new issue for the new occurrence. A person or the agent can also reopen one.
• If the issue links to a component, an open issue moves that component to degraded or outage on the status page, and resolving it returns the component to operational. The status page is in limited release.

To act, ask the agent in the issue thread what changed, or copy the issue's prompt into Claude Code, Codex, Cursor or Devin to fix it in your repository. An Issue triggered notification goes to your in-app feed by default. A delivery rule sends it to Slack, Microsoft Teams or a webhook, optionally filtered by severity, component or owning team. Setup for chat is on the Slack integration page.

What you need

Logs from a production project, and the failing service has to send them. You can also send deployment notifications through the Webhooks source. They land as searchable records next to your logs, so you can ask the agent in an issue thread what shipped around the time a problem began. That step is optional.

What it does not cover

A regression has to show up in your logs or in a client to be seen. A quiet change in behavior with no error, no latency change and no shift in any other watched signal is not covered today. If an issue you expected did not open, check the Intake page first to make sure the data arrived.

Detected issues are metered, so see pricing. The wider view is reliability issues, and the browser-side signal has its own page on client errors.