# Release notes 0.1.180

> 31 October 2026: When a fix fails or is rolled back, the platform starts a new analysis by itself while the incident or finding still waits for a person: once the rollback has landed, or once the…

_Release notes · Updated 2026-10-31 · Describes release 0.1.180_

## 0.1.180 — 31 October 2026 {#0-1-180-31-october-2026}

### Re-analyse after a failed or rolled-back fix {#re-analyse-after-a-failed-or-rolled-back-fix}

- **When a fix fails or is rolled back, the platform starts a new analysis by itself** while the incident or finding still waits for a person: once the rollback has landed, or once the platform has confirmed nothing was applied, at most twice per record. The new analysis is given every earlier attempt (what ran, on which resource, how it ended) and must not propose the same fix again unless it explains what is different. It only proposes: the new fix still needs the usual approval, and nothing runs automatically on a record whose earlier fix failed. The incident page offers **Re-analyse** instead of re-applying a plan that was just rolled back. On by default; switch under Guardrails → Pre-approved auto-fix → "Re-analyse after a failed or rolled-back fix".

### Alerts that name no service {#alerts-that-name-no-service}

- **Before an alert with no service is held for triage, the platform looks up the resources it names** (instance, load balancer, database, function, pod, workload or ARN) in the estate inventory and the service graph, with no model call. When exactly one service owns them, the alert takes that service and opens or joins its incident; "How these were grouped" says why. When nothing or several services match, the alert waits as before and the "Unidentified service — map this source" card shows what the check found. After a miss the inventory and service graph refresh at most once an hour per workspace and the waiting alerts are looked at again. Both are on by default (Settings · Data in → Alert intake & tokens → Intake rules). The lookup only places resources it can tie to a service through a Kubernetes owner, a load-balancer route, an x-ray relation or a service/app/application tag.

### Alert noise, counted per month {#alert-noise-counted-per-month}

- **The dashboard's "Alert noise reduced" figure has a new definition, and the number changes, usually upward.** It is now 1 − incidents ÷ alerts received, for monitoring alerts only, from what intake recorded when each alert arrived. Before, it was the share of stored alerts whose current status was suppressed, which missed cleared alerts and repeats dropped at intake and mixed in scanner findings. The line under it reads "N alerts → M incidents": the large number is the alerts received, not the noise.
- **New "Alerts → incidents · per month" table** on the dashboard and in the service-delivery report (UTC calendar months, back as far as the workspace keeps records): alerts received, duplicates dropped, joined an open incident, incidents, grouped with a related one, closed as noise, and the reduction. Scanner findings have their own table; test alerts are not counted. API `GET /api/aiops/{tenant_id}/dashboard/noise`, MCP tool `dashboard_noise`.

### Agents activity {#agents-activity}

- **New Agents activity page under Insights.** The seven pillar agents run as 18 AI roles; for each role it shows running, queued and waiting jobs, runs, failures and cost over 24 hours, 7 days or 30 days, the average cost per run and the last run, plus the newest runs (linked to their incident, finding or change) and the agents' audit trail. Test Lab runs sit on their own card. Cost columns need `report.view`. Dashboard Pillar health gains agent, job, run, failure and cost columns that open the page filtered to the pillar. The audit log can be filtered by actor.

### Standard changes and approvals {#standard-changes-and-approvals}

- **A standard change scheduled into a closed window records no approval.** The change, its change request document and the incident show "Pre-approved · scheduled for <time>". Before it runs, the incident's Approval line reads "Not needed — pre-approved standard change". Approver notes now also appear on the incident's L5 Approval line and Timeline. The first approver of a two-approver change sees that it runs in the next window. Two-approver (L3), standalone and P1 skill-rule standard changes still need their approvers, pending a decision.

### Findings, numbers and runbooks {#findings-numbers-and-runbooks}

- **Compliance records read as findings across the product**: the audit log, plan text, validation and recheck summaries, plan-review warnings, Needs you, notification digests (incident and finding updates counted separately) and the help chapters. Counts and totals on the remaining pages and in server-written summaries use thousands separators; CSV and JSON downloads keep raw numbers.
- **The suspected-change pin on a security-group finding names only a change that opened, to the internet, a rule the finding reports**, so "Roll back first" no longer offers to undo the fix that closed an earlier rule. A platform change that was already rolled back is never pinned as a cause.
- **A finding that returns on the same resource demotes the certified runbook at once**; if the cloud audit log later delivers the outside change that explains it, the runbook is certified again and a request drafted meanwhile goes back to standard at its own tier, including an emergency draft for a P1 or critical finding. A class a person chose, or a request already requested, approved or released, is never changed.


## Next steps

- Next: [Release notes 0.1.179](/help/release-notes-0-1-179.md)
- [All What's new pages](/help/what-s-new/llms.txt)
- [Documentation home](/help/)