What's new

The customer-visible changes in 0.1.146 to 0.1.164 and in 0.1.130 to 0.1.133 — what changed on your screens and in the API, and what you may need to do after each upgrade.

Release notes · Updated 2026-10-28 · Describes release 0.1.164

The latest releases, newest first, as they look from a workspace. GET /healthz reports the version you are running. Platform-console changes are marked (platform console): they concern your platform administrator, not your workspace screens.

0.1.164 — 28 October 2026

A runbook demoted before the outside write that explains its recurrence was harvested gets its certification back when the write arrives, and the Changes list loads faster. The full list is in the release notes.

What changed

• A late outside write gives the runbook back. A cloud audit log delivers a write minutes after the recurrence it explains opens, so the runbook was demoted before the write could explain it. After each harvest that records a write, the platform checks the last 24 hours' unexplained marks again: a mark the write explains stops counting against the fix (Recorded fix recurrence explained by an outside change), the runbook that recurrence demoted is certified again with the certification it held (Runbook certification restored — an outside change explains the recurrence), and the recurrence's change request that nobody has requested yet goes back to standard (Change class restored — the runbook was certified again). A runbook demoted again since, disabled, edited, re-certified or kept manual by a person stays demoted. The route row still reads certification kept. See Runbook library.
• Pages. The Changes list loads several times faster. An id, ARN or region in the knowledge, scope, dashboard and audit cells breaks after a separator first, and a sha256 digest shows its first 12 hex digits with the whole value on hover. The list of EC2 instances not managed by SSM on Security posture fits its card.

What you may need to do

• Nothing. A runbook demoted before this release is not restored automatically: an approver certifies it again.

0.1.163 — 28 October 2026

An outside change and the scanner finding that followed it now meet on the finding, two Guardrails switches are on by default, and the scanner register clears the findings no read could. The full list is in the release notes.

What changed

• The write behind a scanner finding. An unmanaged cloud write on a finding's resource in the 24 hours before the finding started failing is listed under Changes that triggered this check on the finding's incident (timeline: Captured change named on this finding), and the change gets a re-checked by Security Hub · EC2.19 · failed chip that links back (timeline: Scanner finding failed after this change). It is detection, not proof of cause: nothing changes status. See Review execution in Changes.
• Two switches on by default. Keep an incident open while its fix waits for a decision: an escalated incident whose change request was requested, or whose proposed fix matched a certified runbook, no longer closes on the quiet window or when its ticket closes at the source. Refuse a change when its before-state cannot be captured: a direct cloud write runs only after the platform has read and stored the resource's current state, so a step over a CLI connection, or a route that declares no snapshot read, is offered on the manual route only, and a read that fails at release stops before the write. A workspace that set either switch keeps its own value: a box unticked on 0.1.162 stays unticked. See Guardrails and cost limits.
• Findings the scanner no longer reports. An open Security Hub finding the hub no longer answers, last seen over 48 hours ago, clears as no longer reported by the scanner — after 90 days for a finding of an account the pull cannot read — and, when every pulling connection is tag-scoped, a finding on a resource outside the scope clears as out of scope. Neither counts as fixed. A tag-scoped connection now also lands the Inspector CVEs of tagged ECR repositories and Lambda functions. See Compliance reference.
• Backup list. The DynamoDB.1, DynamoDB.6, ELB.6, Cognito.6 and RDS.8 findings leave the Backup list: every stored finding is classified again once.
• Built-in alerts join their service. A built-in metric alert takes the service its resource's tags name (service, app, application or Name), so an alert on an EC2 instance tagged service=web joins web's other alerts instead of opening its own incident. See Built-in detection.
• Crash loops between back-offs. Pod crash loop (R31) also fires for a container restarted 3 times or more that crashed again since the previous read; a node reboot is no crash loop. See Built-in detection.
• Upgrade warning. A package, runtime, image or OS-patch upgrade carries an Upgrade warning in its change request and under Affected resources & blast radius: what runs on the target, who calls it and the known breaking changes, else unknown, not checked.
• Approvals. A release whose approvals lapsed before it ran waits for approval again instead of failing, each vote listed once.
• Pages. Alerts searches the whole view on the server (alert, service or label), not only the page already loaded; every Status and Source count on Changes is the total of the list it opens; tables fit their card and break an id only after a separator. Thresholds and why is its own page: Thresholds and why.

What you may need to do

• Review runbooks and routes that write over a CLI connection or declare no snapshot read: with Refuse a change when its before-state cannot be captured on they are manual-only. Use the native API connection, or untick the switch under Guardrails → Change safety to keep the 0.1.162 rule.
• To close escalated incidents on the quiet window even while a fix waits, untick Keep an incident open while its fix waits for a decision.
• A workspace that saved either switch keeps that value; through the API, PATCH /guardrails with null for hold_for_approval or require_before_state follows the platform default again.

0.1.162 — 27 October 2026

Fixes from the live read-back of 0.1.161, where real rows were longer than the sample data: three list tables fit their card again, a change request stored before 0.1.161 reads its blast radius in the current words, and the dark theme draws checkboxes dark. The full list is in the release notes.

What changed

• Tables fit their card again. The findings list under Security posture fits from 1280 px: a resource named by a long digest is cut to the Finding column with the whole name on hover, a long source and a Fixed — awaiting CSPM chip wrap at their spaces, and the Finding column keeps room for its title. The runbook catalog fits at 1024 and 1280 px: a resource type breaks after a dot or an underscore, and the Published by AWS line between the words of the document's name. Who changed what on Changes fits at 1024 px: a long actor is cut with the whole name on hover. On Problems, a blocked route's operations break only after a dot again (0.1.161 split them mid-name). See How incidents work and Write, verify and certify a runbook.
• Older change requests in the current words. A change request whose blast radius was stored before 0.1.161 printed the generic estimate note and the specific reason together, a folded coverage-gap sentence, and the change management agent's bare No impact beside Estimated impact. The card under Affected resources & blast radius and the document's 2.4 Impact and 2.5 Risk now print the specific reason alone, the old gap as Coverage gap recorded before 0.1.161, not split by kind: …, and the bare No impact as The change management agent's note: No impact (drafted over an earlier report) or (drafted before this estimate's basis was shown). An RCA's blast radius section is headed by the same basis label (Blast radius — Estimated impact) with the same basis sentence. See The change request document.
• Dark checkboxes in the dark theme. The Estate map's checkboxes were bright white squares in the dark theme; checkboxes, radio buttons, select lists and scrollbars now draw dark on every page.

What you may need to do

• Nothing. An RCA written before the upgrade keeps its text.

0.1.161 — 27 October 2026

The Dashboard after its first day on a live workspace: the hub keeps its shape at every window width, the page shows the three pillars the product sells today, a ring and its Pillar health row read one unresolved, and the MTTA and MTTR tiles say how many incidents they rest on. List tables fit the page, a change request's blast radius says its basis and the map's gaps once, in plain words, and the Estate map lists a Lambda function once instead of twice. The full list is in the release notes.

What changed

• The hub keeps its shape at every width. The pillar rings sit on one circle around the Human gate, evenly spaced from the top (three pillars: top, lower left, lower right), and the picture scales with the window, so a ring never sits on the gate or hides its label — at 1950 px the SecOps ring did.
• Three pillars until you list more. The Dashboard shows Incident & Problem, Compliance and Change Mgmt: their rings, Pillar health rows and sections. SecOps, FinOps · Optimise and Continuous Improve are hidden until a workspace owner lists them on Guardrails → Dashboard pillars (dashboard_pillars on GET/PATCH /guardrails); their counts stay in the summary, and the hub copy reads across the pillars this dashboard shows. See Dashboard.
• One "unresolved" per pillar. A ring, its Pillar health row (the column now reads Unresolved) and its section headline show the same number — the total of the list the ring opens. The Incident ring read 19 while the row read 3; both now read the Incidents list's unresolved rows, and the sidebar's Incidents badge shows the same number. The section links read Unresolved incidents, Unresolved findings and Waiting for approval.
• Honest MTTA and MTTR. The tiles print the rows they rest on (over 7 resolved incidents) and compare with the previous 30 days only from five or more incidents a side; with fewer they read too few to compare. An MTTA under a minute reads under a minute · analysis starts on open instead of 0s.
• Tables fit the page. From 1024 px the Incidents list and the other list tables fit their card instead of scrolling sideways: a long key, ARN or title breaks inside its column (a denied-access report's assumed-role ARN widened the list on exactly that row), dates break only between the date and the time, and emails stay on one line. A table whose columns cannot share one screen, such as a Lakehouse query result, scrolls inside its own box. Archive shows the Closed and Archived dates again.
• The blast radius in plain words. Under Affected resources & blast radius the card prints one basis sentence (Estimate: computed from the target's direct neighbours in the estate map; this operation has no exact before/after delta., or the report's own reason), then the map's coverage gaps one line per kind against the whole map (N of M resources in the estate map: no relationship model yet …, … stale after the last harvest, left out of reasoning, … inconsistent between sources, left out of reasoning), never counting a resource twice. The change management agent's words read as a conclusion on the same basis only while the report shown is the one its draft read; otherwise they show as written. The change request document's 2.4 Impact prints the same lines, and 2.5 Risk cites the blast radius it weighs. See The change request document.
• A function once on the Estate map. Resource Explorer and AWS Config list a Lambda function once per version and alias; the map now keys them by the function, so a second card named $LATEST no longer appears, and a change that names an alias (…:function:<name>:live) finds the function. More than twenty objects of one class with the same neighbours fold into one group node; a search or a Type filter still lists its hits one by one. See Estate harvest and x-ray.

What you may need to do

• Nothing for the upgrade itself. A workspace that wants SecOps, FinOps · Optimise or Continuous Improve back on its Dashboard lists them under Guardrails → Dashboard pillars (members.manage); Follow the platform default returns to the three.
• A map harvested before 0.1.161 still holds a $LATEST card per Lambda function until the next estate harvest of that AWS read connection: the scheduled one (daily by default), or Harvest now on the Estate map (every eligible connection) or on the connection's row in Data sources (datasources.manage). That harvest folds the duplicates into the function's node. A change request keeps the blast radius it stored until its review or preview is opened again.

0.1.160 — 27 October 2026

The overall Dashboard — the structure of the customer's "Mission Overview" mock-up on the platform's own counts — and two Problems page fixes from the 27 October live runs: a blocked route's operations stay inside their cell, and a recurrence that a recorded outside change explains no longer counts against automating a fix. The full list is in the release notes.

What changed

• The overall dashboard. Dashboard is the first item in the sidebar and the home once the workspace has an enabled read connection (/portal/ sends you there; a workspace without one still sees the Quick start once per browser session, then the Dashboard with a Connect your first data source card). It inherits the mock-up's structure and fills it with what the platform records: the hub — six pillar rings (Incident, Compliance, Change, SecOps, FinOps, Improve) around the Human gate, every write a person must release before it runs; the four service KPIs — MTTR, MTTA, Alert noise reduced, Auto-handled events — over the last 30 days against the 30 before, with sparklines; Pillar health beside the Human gate queue (the Needs you rows, with the tier and who must release each); one section per enabled pillar — Incident & Problem with the pipeline strip and the newest unresolved incidents, Compliance by domain with the scanners' own standards, Change management, SecOps, FinOps · Optimise and Continuous improvement — and the Guardrails — always on strip. Every number is read in one request, cached for a minute, and a number that is a link opens the list whose total it is, with the same filter: the Incident ring opens Incidents under Unresolved (any but resolved), the Change ring Changes under pending approval, the Improve ring Problems under open, the FinOps ring Usage & billing (for people with report.view, who alone see the spend figures; others see a dash and no FinOps section). FinOps shows the AI agents' own spend only: the platform holds no cloud cost data, and cloud spend stays in the cloud's cost tools. A pillar the platform switched off shows a dashed ring reading off and no section; a figure the rows cannot support says so. The decisions the mock-up did not make — what the hub's centre counts, where MTTR ends, where problems sit, the dashed ring, the workspace-wide pipeline strip, the one-minute cache — are listed as (proposed) in the chapter, with what was left out and why. The former dashboard is replaced. See Dashboard.
• A blocked route's operations stay inside the Problems cell. The Automation column lists a blocked route's operations one per line and wraps the reason, instead of running one unbreakable a+b+c token into First seen; a long correlation key breaks inside the Problem column, so the table never widens.
• A recurrence an outside change explains no longer counts against a fix. When someone wrote the same resource from outside the platform between a fix and the recurrence (a cloud write the platform's own audit harvest recorded — AWS CloudTrail, Azure Activity Log — by a principal that is not the platform's, after the fix's verified clear), the mark names that change and is not counted: the record reads recurred after an outside change on the Artifacts card and on the incident page, Problems and the problem detail show recurred after an outside change ×N beside the automation facts, never as a block, the automatic step lane and the known-issue fast path do not call such a fix one that did not hold, and the audit row names the change. A recurrence nothing explains still marks the fix did not hold. See Read an incident.
• Every portal page checked for text wider than its box. A release check now opens every portal page at laptop and phone widths, light and dark, and fails on any text box wider than itself. Its first run fixed the stat tiles on Audit & coverage → Frameworks and Posture's Backup card, the Needs you rows on a phone, the Estate x-ray category labels and the lab's plan list.

What you may need to do

• Nothing. The partial index the recurrence rule reads is built in the background after the upgrade, while the platform serves (on a large change ledger the build takes longer; until then that read is slower, not wrong). Recurrences marked before this release keep counting as they did: existing problem rows are not rewritten; a problem that reads did not hold ×N for an outside change needs its next recurrence, not a re-count. Bookmarks to /portal/ still open the Dashboard.

0.1.159 — 27 October 2026

Fixes from the live runs of 26 and 27 October: a Lambda runtime upgrade is verified by reading the function back at no cost, a runbook that no longer backs a change reads the same way on every screen, a stored call's placeholders read as the values its run filled in, and a runbook captured from a published document says where it came from. The full list is in the release notes.

What changed

• A Lambda runtime upgrade verifies at no cost. A runtime-upgrade change no longer reads not read: no compiled check for a Lambda function and no longer waits for the scanner's clear: the platform reads the function back itself — the runtime the step sent with LastUpdateStatus Successful and State Active or Inactive, and the alias on the version the run published — and the validation plan's rows and the post-fix check land the verdict with no agent run. The derived metric window still watches the function's error rate after the alias moves; a window with no datapoints decides nothing, and the reads decide once it closes. A released or verified fix stamps only the finding of the function it wrote to. See Runbooks and automatic fixes and Verify recovery.
• Why a runbook no longer backs a change, in one vocabulary. The change page's Class block and Timeline, the incident page, the runbook catalog and the route row say the same thing: certification withdrawn by a person, runbook demoted after a rollback, after a failed validation or after a fix that did not hold, runbook disabled, deleted, no longer certified or changed since the request was drafted; a request from before this release reads runbook no longer backs it. A demotion reason the screen does not know reads as its own words, never as a rollback. See Changes reference and Runbook library.
• A stored call's placeholders read as values. On the change page, a step the run has executed reads the version it published, the version the alias pointed at before and the change's own CHG-… where its request body carried ${…} slots; a step not run yet reads them in plain words, never as a raw placeholder.
• Where a published runbook came from. In Agent quality → Runbooks and on the route row, a runbook captured from a published document reads Published by AWS · <document> · Automated Security Response on AWS v4.1.0 under its name, and the catalog search finds it by the document name. See Runbook library.

What you may need to do

• Nothing for the upgrade itself. A Lambda runtime-upgrade change still verifying at the upgrade reads its function back on its next check and lands at no cost once its metric window closes; a change whose standard class dropped before the upgrade keeps reading runbook no longer backs it.

0.1.158 — 27 October 2026

Fixes from the live read-back of 0.1.157: a certified runbook is no longer demoted for a recurrence an outside change explains, the AWS-published runbooks reach every workspace with an AWS write connection, a refused scheduled release says why, and two lines read in words. The full list is in the release notes.

What changed

• A runbook is not blamed for an outside change. With Demote a certified runbook when its fix deviates on, a fix that did not hold no longer demotes the runbook when the platform's own cloud audit harvest recorded a write by someone other than the platform on the same resource between the fix and the recurrence: the certification stays, the incident Timeline reads Runbook kept — an outside change explains the recurrence, and the route page names the change that explains it. A run that fails its validation is still demoted. See Runbook library.
• A refused scheduled release says why. A release scheduled while the change was standard and refused at its time because the class dropped now says what dropped, that the approvals it had no longer count, and that you review the change again, then release it or schedule it again — on the change page, in the audit and in the notification. See Change control.
• The AWS-published runbooks in your workspace. A workspace with an AWS write or read/write connection receives the five step runbooks captured from Automated Security Response on AWS, listed in Agent quality → Runbooks as Not certified · disabled and bound to the oldest such connection; nothing enables them on its own — point one at the connection you want and have an approver certify it. They are added once: one you delete or rename stays gone. See Runbook library.
• Two lines read in words. The Approvals card of an automatically released change reads Released automatically — Platform (pre-approved) instead of an actor id, and the Patch compliance card on the Scores page says how the optional patch-age rule is set instead of printing a stored setting name.

What you may need to do

• Nothing for the upgrade itself. Within a minute of it, every workspace with an AWS write connection lists the five AWS-published runbooks, disabled and not certified; delete the ones you do not want — they are not added again.
• A runbook demoted on 0.1.157 for a recurrence an outside change explains stays demoted: an approver certifies it again.

0.1.157 — 27 October 2026

Scheduling and patch windows, the runbook library, the change management agent's evidence, runbooks in plain words with platform step templates and a catalog, the display faults from the 26 October demo, and the setup and documentation items. The full list is in the release notes.

What changed

• Approve and schedule. The release dialog of a compliance or vulnerability change offers When to run: now, at a time, or when the service's maintenance window next opens; the platform releases it then as the person who scheduled it, with the same checks as a click, and the change page shows Reschedule and Cancel schedule. A Patch schedules row plans one change request per service window for the instances Patch Manager reports non-compliant, waiting for your approval. See Change control.
• One resource first (off by default). With Run a multi-resource change one resource first on, a change that writes to several resources runs the first, reads it back with its own checks and only then the rest; a failed check stops the run with only that resource to roll back. See Settings added since 0.1.157.
• A runbook is for a use case, never one resource. The quality check reports a target or selector pinned to one resource, certification refuses it, and a runbook certified before the rule no longer runs. See Runbook library.
• A certified runbook is demoted when its fix deviates (on by default): a run that fails its validation, or whose fix does not hold, takes the certification away until an approver certifies it again; Needs you lists it. See Guardrails.
• Runbooks in plain words, platform step templates and a catalog. Every step runbook has a purpose, when to use, its steps in plain words, risks and backout — generated from the steps where you wrote nothing — shown at approval and in Section 4 of the change request document; a step may name a platform template (Add platform step); Agent quality → Runbooks lists every runbook behind one search box; a certified runbook for the incident's service reaches the analysis as knowledge; a package-upgrade step (aws.ssm.upgrade_packages) and five AWS-published Security Hub fixes come as step runbooks. See Write, verify and certify a runbook.
• Snapshots and the impact in plain words. Every resource a change writes is read before, after each step and after the change (Resource snapshots on the change page, Section 8 of the document), and the change agent writes what could break and how beside the computed blast radius. The analysis prompt now states when a change counts as the cause. See How the platform finds the last-known change.
• Dashboards, the service graph and the demo's display faults. The Incidents, Compliance findings and Changes lists open with counts by severity and status and a 14-day trend, each count a filter; the service group draws the graph one and two hops out; a refused rollback reads Rollback failed with the provider's code, a check whose write never ran reads Not run, people read by name, and a record cleared because its resource left the tag scope is no longer counted as fixed.
• Tag-scoped guided setup. The guided AWS setup offers Leave out account-wide settings (shared account) for a writer without the three account-wide statements. What counts as a repeated incident is a switch (off keeps today's rule). See Set up AWS and Unauthorized changes.

What you may need to do

• Nothing for the upgrade itself. A step runbook certified before this release with a resource written into it as a literal target, or a selector naming one resource, no longer runs: give it a parameter bound from a label or annotation and certify it again (Agent quality → Runbooks shows the finding).
• Re-run the guided AWS setup only if you want the shared-account writer option; the choice is not remembered on a re-run.
• Add ssm:SendCommand on AWS-RunShellScript to the write role before certifying a runbook with a package-upgrade step; the guided role does not grant it.
• Set Demote a certified runbook when its fix deviates off on Guardrails if you want the 0.1.156 behaviour, where only a rollback demotes.

0.1.156 — 27 October 2026

Four security hardening waves — identity, private agents, change integrity and the connector tools — and three fixes from the live run of 0.1.155. The full list is in the release notes.

What changed

• A change ticket vouches for a write only with its own token. A ServiceNow or Jira change ticket accounts for a captured write under unauthorized-change detection only when your ITSM sends it with the workspace's new ITSM webhook token; one sent with the shared webhook token, or through your own change feed, is recorded and never covers a write. See Changes.
• Each cluster's audit webhook has its own token. The Kubernetes audit webhook takes the cluster's audit token, never the shared webhook token, and the form without the cluster name answers 404. See the audit webhook.
• A kubeconfig is a static identity. A kubeconfig that runs a credential plugin or names a file on the platform host is refused at save and at every use; a static or service-account token with embedded certificate data works. See Kubernetes (kubectl).
• Release decisions stay with approvers. Re-pointing a write connection's credential or role needs approvals.decide; an L3 release counts a vote only for the command it released and only from a current approver; the freeze window judges a captured write at the provider's time; a refused rollback can be released again by a person.
• Passwords and sessions. Platform staff no longer set a password on a workspace account; Reset password on a member's row, or a staff-emailed link, replaces it. A password change ends the account's other sessions, and an account born from single sign-on signs in only through it. See Members and roles.
• Workspace chat is answered only by an agent your owner designated with Answers workspace chat; agents that already answered keep doing so.
• Bounded reads everywhere. Answers from the endpoints you connect, identity providers included, are capped and time-boxed; PDF extraction and probe slots are shared per workspace; approval records and chat tools hide credentials the way the approval page does.

What you may need to do

• Mint the ITSM webhook token and send change tickets with it; mint each self-managed cluster's audit token and restart its API server. Both are API or MCP calls; the upgrade row lists the steps.
• Re-save a kubectl connection whose kubeconfig uses exec, auth-provider or a file path, with a static token and embedded certificate data; add a service-account key to a Google Cloud connection saved without one.
• Scripts that saved the change statistics or model report with GET …?export=true now call POST at the same path.

0.1.155 — 26 October 2026

Fixes from the live tests of 0.1.154, a Lambda runtime upgrade runbook and a not needed end state for a change. The full list is in the release notes.

What changed

• A finding is fixed only after a person approves it. A compliance control, scanner finding, vulnerability or security alert never runs on its own, on any automatic lane and whatever runbook matches; an incident's fix still can. With Let the analysis pick a matching route instead of typed steps on and a write-capable connection, a finding's analysis may now name a certified step runbook that matches it, and a person releases that change. See Runbooks and automatic fixes.
• Roll back a patch from its own backup. The EC2 patch runbook's rollback restores the root volume from the pre-change image the platform made, into a new volume. The change request prints the runbook's own rollback lines, is drafted at the tier its release needs, and its post-change check reads the patch result and the restored groups, not the power state.
• Lambda runtime upgrade runbook. A version backup, the new runtime on $LATEST, then the alias, each guarded by the revision it read; the platform never uploads code. See The Lambda runtime upgrade.
• Not needed. A change whose only target already complies ends Not needed, with nothing to roll back, instead of failed.
• Tickets. Filed tickets fill the fields the platform requires of incoming ones where the ticket system knows the value, the Notify line names only channels that deliver, a person's resolve note leads the write-back, and Send test ticket works on a disabled route. See Ticket systems.
• Less noise, fewer wrong folds. EKS's own controllers and kubectl auth whoami are no longer recorded as changes, a pipeline's refused write is kept as a denied attempt, and a scanner finding is never folded into another incident by its change window.

What you may need to do

• Run the AWS setup again (or re-apply deploy/aws): the write role gains the restore from its own backup, Reachability on network interfaces and the Lambda runtime upgrade, and its permissions move into one inline and four managed policies, which the re-run creates; nothing needs deleting first. Re-applying deploy/aws also updates the image rebuild's buildspec. See Connect AWS.
• On a Jira or Azure DevOps ticket route, run Check and save the route again so filed tickets fill the component, assignee or priority.

0.1.154 — 25 October 2026

A container image rebuilt under a new tag, an opt-in block of pulls, neighbour reachability in a fix's validation, and a permission check that no longer reads a missing permission as unknown. The full list is in the release notes.

What changed

• Rebuild a vulnerable container image with a step runbook. aws.ecr.rebuild_image starts one build of your own CodeBuild project aiops-image-rebuild: it upgrades the packages the scanner named on top of the image and pushes the result under a new -aiops-chg- tag. Nothing running changes; the deploy stays yours. See Container image rebuild.
• New image built, not deployed. While the scanner still reports the old digest, the incident and finding pages say so with the new tag, and targets that take image_not_deployed are reminded every 24 hours (aiops_image_reminder_h). Moving the workloads alone does not stop it: the old digest stays in the registry and is still scanned, so delete or untag it once nothing runs it. See Set up notifications.
• Block pulls of a vulnerable image, opt-in. With Allow a runbook to block pulls of a vulnerable image on (Change safety, off by default), a runbook step adds one Deny statement to the image's repository policy — every image of that repository, released at L3, undone by Roll back. See Block pulls of this image.
• Neighbour reachability in the validation rounds, opt-in. With aiops_reachability_checks on (API only, off by default), a fix's validation asks AWS Reachability Analyzer whether a path exists between the changed instance and each one-hop neighbour that has an EC2 network interface in the estate model (not one behind a load balancer's target group); about USD 0.10 per analysis, billed to your AWS account. See Verify recovery.
• The permission check says missing when a permission is missing. A step runbook whose write role lacks an action it needs — or grants it only under a condition the check cannot supply — now reads missing and is not certified; before, IAM's list of condition keys made it read unknown. Unknown does not mean granted: a person releases that runbook's changes. See Step runbooks.

What you may need to do

• Run the AWS setup again: the write role gains the image rebuild's codebuild:StartBuild and codebuild:BatchGetBuilds on the project aiops-image-rebuild and ecr:DescribeImages. Create the project with deploy/aws (image_rebuild = true), tag its repositories aiops-managed=true and make those repositories' tags immutable. See Connect AWS.
• A write role from deploy/aws scoped by another resource_tag_key / resource_tag_value: paste the re-applied module's datasource_snippet scope (it now carries resource_tag) into the write connection's Scope JSON, or its step runbooks read missing and are not certified.
• On each certified step runbook, press Check the write connection's permissions: a role that lacks a permission now reads missing. Grant it, then certify again.

0.1.153 — 25 October 2026

Tickets that must name their fields, an EC2 patch runbook, and built-in detection that raises degradation, Kubernetes state, scheduled maintenance and provider issues. The full list is in the release notes.

What changed

• A ticket sent in must name service, severity, priority, assignee and notify. A Jira, ServiceNow or Azure DevOps ticket missing any waits in the triage queue, wearing awaiting info, and AIOps asks on the ticket once for what is missing; the update that names them moves it on. See Tickets that come in must name five fields.
• Patch an EC2 instance with a step runbook. Back it up, move it to an isolation group, install the missing patches and put its groups back. The demo workspace's disabled example route EXAMPLE: EC2 patch with backup and isolation holds it; other workspaces create it from the request in the chapter. See The EC2 patch runbook.
• Patching findings. The daily Patch Manager read opens a Patching finding for each non-compliant managed node, unless Security Hub's SSM.2 already holds it open. See Security posture.
• Built-in detection watches more. Latency and fault rates against their own baseline (R26–R28), EKS failed nodes and restarting pods (R29, R30), Kubernetes pod and node state through a read-only kubectl connection (R31–R34), EC2 and RDS scheduled maintenance as P4 incidents (R35, R36; our proposal) and AWS Health issues the estate is exposed to as P2 incidents (R37). See Proactive monitoring.
• New rules start in shadow. On a workspace already armed, R26–R37 watch in shadow for the shadow period (24 hours by default) before they open anything; Arm now arms them at the next poll. See New rules start in shadow.
• The relevancy says when the last fix did not hold. Triage step 2 reads its last fix did not hold N times in 30 days — no fast path instead of no verified fix record.

What you may need to do

• Before upgrading, update the ServiceNow inbound business rule (template), name the severity and who to notify on Jira issues (a Severity: / Notify: line or label: Jira has no field for either), tag Azure DevOps work items service:<name> and notify:<team>, and make sure Jira jira:issue_updated and Azure DevOps workitem.updated reach the platform — or narrow ticket_required_fields first. Otherwise tickets missing a field wait in the triage queue. Even [] holds a ticket that names no service while aiops_unmapped_triage is on (the default).
• Run the AWS setup again: the read role gains rds:DescribePendingMaintenanceActions, the write role ec2:ModifyNetworkInterfaceAttribute and ssm:DescribeInstancePatchStates. Tag the instances' network interfaces aiops-managed=true for the patch runbook. See Connect AWS.
• Where Patching findings should not start an analysis on the first read, set aiops_patch_findings to false before the upgrade.

0.1.152 — 25 October 2026

A hotfix from the live test of 0.1.151. The full list is in the release notes.

What changed

• A change on the fixed resource lowers the known-issue relevancy. A change recorded since the last verified fix on the instance or volume it touched — by an operator, a pipeline or the cloud console — now reads 85 % and changed since the fix: CHG-…, whether the change names the resource by its id or its ARN, so the analysis runs in full instead of the 3-step fast path. See The incident page.
• The shortened analysis says whether the last fix held. It reads a verified fix that did not hold (N× in 30 days) when the same alert came back after it, never held.
• A new incident of a resolved alert reads recurring ×N. The header chip, the incident list and triage step 2 said reopened although the incident had not reopened. reopened now means the incident came back after its own close. See Reopened, repeated or new.
• The Probable cause card's look-back sentence matches the API. A reopened incident whose previous episode has no recorded end reads No recorded end of this incident's previous episode within the 72 h look-back — not proven healthy, no longer No earlier error….

What you may need to do

• Nothing.

0.1.151 — 25 October 2026

A hotfix from the live test of 0.1.150. The full list is in the release notes.

What changed

• A certified step runbook with a backup runs on its own again. With both automatic-fix switches on, a runbook that backs up an instance before starting it approved its own release and then refused it, so nothing ran. The incident page, the change page, the approval and the release now estimate the same blast radius, and a backup's own image no longer stops the steps after it. See Step runbooks.
• The Timeline says when an automatic fix never ran. It reads Automatic fix refused before dispatch · nothing ran: … when the check before the first step refused the release, and Automatic fix failed · stopped before step N: … when the check before a later step stopped it.
• The probable cause reads the incident's own, current alert. When another service's incident was merged, folded or grouped into this one, the error start, the ranking, the RCA Timeline and the triage's resources come from this incident's own alerts, never the merged one, and the error start from the alert that opened its current episode. A reopened incident is ranked from where its previous episode ended, and a fix the platform made for the incident is never offered as its cause. See Probable cause.
• A fix validates sooner when its first round came too early. When only round 1 read no data and every later round was clean, one more round is read in its place, and the result says after 1 added round (round 1 read no data). The post-fix check now takes an incident whose fix ran before the workspace's other open incidents. See Verify recovery.
• A resolved incident shows its latest resolution. After a reopen, the next close drops the note an earlier episode closed with; a note written for that close stays.
• Model calls use the platform's usual HTTP client (platform console): no more Unclosed client session errors in the control-plane log. Proxy settings still apply; NO_PROXY entries are matched by httpx's rules.

What you may need to do

• An approval recorded on the incident page before the upgrade for a runbook fix with a backup step may be asked for again: approve it again. Nothing ran under it.

0.1.150 — 25 October 2026

A hotfix from the live test of 0.1.149. The full list is in the release notes.

What changed

• A fix acts on the incident's own resource. When another service's incident was merged, folded or grouped into this one, a runbook takes its target from this incident's own alert, never the merged one. A fix from a step runbook or the analysis with a step on a resource only a merged-in alert names is never a standard change and is never released, by a person or automatically: its review says which step names which resource. See Change classes.
• A clear is credited only to a fix that could have made it. When the change that ran acted only on another resource and the incident then cleared, the change completes with the verdict uncertain and earns no last-known-good or runbook credit; the Timeline reads Clear not credited to the fix that ran.
• A silent alarm no longer reads as a clean validation round. A round is clean only when every one of the incident's own alarms passed; an alarm that reads no data fails the round when it treats missing data as breaching and is still in ALARM (a stopped instance). An alarm merged in from another service only flags a round. Every item of the validation plan (V1, V2, …) reports in every round. See Verify recovery.
• The releaser is named beside the approver. A change approved by one person and run by another records both: the change request document lists Approved by and Released by, and L5 reads Approved by … · released by ….
• A reopen chooses its suspected change again, so a reopened incident no longer carries the suspected change-induced pin of an earlier episode.

What you may need to do

• A change request drafted before the upgrade for an incident that holds a merged-in alert keeps its class, but its release is refused if a step acts on the merged-in resource: re-analyse the incident for a new request.
• A CloudWatch alarm on a count that publishes nothing while healthy (errors, 5xx) should treat missing data as not breaching. With the default (missing), a validation round in which it reads no data is not clean, and the fix goes to the agent verify.

0.1.149 — 24 October 2026

Groundwork for larger installations; most of it is invisible from a workspace.

What changed

• Webhook bodies are capped. A body over 1 MiB is answered 413 before it is read; Alertmanager, Grafana and the generic intake, which send a whole alert group at once, accept 8 MiB, and the Kubernetes audit webhook 16 MiB. A sender does not retry a 413, so a grouped notification over its cap is dropped. See Webhook reference.
• Live pages hold no database transaction between events, so an open incident or chat page never holds up an upgrade.
• Upgrades no longer slow down with your history. Indexes and one-off data fixes run in the background once the platform serves, without pausing alerts or the API. (platform console) Progress is in the migrations block of the admin overview API.

What you may need to do

• If a source sends large grouped notifications, set max_alerts on its Alertmanager webhook_configs entry, or ask your platform administrator to raise the cap (AIOPS_WEBHOOK_MAX_BODY_BYTES).
• A Kubernetes audit webhook behind ingress-nginx is limited to its proxy-body-size (1 MiB by default) first: raise it to 16m or lower the batch size. See the audit webhook.

0.1.148 — 24 October 2026

A hotfix from the live test of 0.1.147. The full list is in the release notes.

What changed

• Two-person release works again. An approver approves and another person allowed to release the tier presses Approve & run: the change runs. A release refused at dispatch now says why on the change (change.release_refused), and an approval whose approver may no longer release the tier is replaced by the click of the person releasing; the dropped approval is listed as such (Approval no longer counts) and no longer counted on the button. See Change classes.
• A noise close stays closed. An incident you closed as known noise is not reopened by the next alert on its key: a new incident opens with the similar: noise chip. For a cloud alert, repeated now means the same resource, not another instance on the same metric.
• The grouping wait. An incident on a service that depends on another waits up to 300 s for that service's own alert before its analysis starts (Held for triage — grouping window: …; Analysis held — grouping wait on the Timeline), so an outage on two related services gets one incident and one analysis. Analyse starts it at once; a P1, a member's concern and a potential root never wait, and an alert whose earlier episode cleared inside the wait is analysed at once when it comes back. See Alert storm: grouped by the service graph.
• The tag scope reaches more of the product. A connection's Only findings on resources tagged now also limits Backup findings and the Backup coverage, suggested synthetic checks and built-in detection; what was already open on another team's resources clears once. A tag value none of the connection's resources carries (or a scope that cannot be read) clears nothing. Denied-access and unauthorized-change incidents from CloudTrail are not limited by it yet. See Security posture and Synthetic checks.
• Close without verdict. A released change whose verification never concluded can be closed by an approver after 24 hours, with a reason; nothing rolls back on the close. See Change control.
• Smaller fixes: a failed execution reads Change execution failed in the history; the failed step of a runbook is the step that failed; the change request's Section 4 lists the backup command; L6 shows what the validation rounds read for each listed item; the Backup list holds backup rules only; a finished Test Lab run's change no longer blocks deleting a connection.

What you may need to do

• A change the 0.1.147 release refused at dispatch stays rejected: its incident needs a new change request.
• To shorten or turn off the grouping wait, set the new workspace setting aiops_grouping_wait_s (whole seconds, at most 600; 0 = off). It is separate from aiops_storm_group_window_s: a raised group window does not lengthen the wait.
• Check that each AWS read connection's Only findings on resources tagged carries the exact tag value your resources use: a value none of them carries clears nothing, and the Backup card says so.

0.1.147 — 24 October 2026

Changes from the customer reviews of 22 and 23 October.

What changed

• Grouping by the service graph, not a count. There is no storm threshold and no storm incident any more. Services failing together on a recorded dependency become one incident on the top-most failing service, at once over the dependencies allowed to fold and otherwise by the grouping agent (on by default); unrelated services stay separate incidents however many alert at once (an alert name already firing on 3 services still joins their incident). The root's L2 layer shows How these were grouped, and a merged incident names its root. See Alert storm: grouped by the service graph.
• A known issue is analysed briefly. Compare against known issues carries a Relevancy level. At 100 % (the same issue fixed and verified in the last 30 days, nothing changed since) an alert-started analysis, never a P1, is capped at 3 steps. The analysis also gets the service's resources from the estate model before it starts, and the cloud-health check covers the accounts and regions they run in.
• Noise closes carry over. When a person closed the previous incident with the same key as known noise, the next one carries a similar: noise chip that links to it and names who closed it. It is a hint only.
• Post-change validation in rounds. A fix is read three times, five minutes apart, against the Post-change validation rules or, when none matches, against the signals its change request's validation plan names; every round clean with the alerts cleared validates the fix, every round failed fails it. For 10 minutes after a start or reboot no paid verify runs. See Verify recovery.
• Synthetic checks. Settings · Data in → Synthetic checks probes a URL or a TCP port every few minutes and opens an incident when it stops answering; checks suggested from your load balancers and APIs probe them in trial, opening nothing, until you keep them. See Synthetic checks.
• Reject a change request. Reject on the change page, with a reason, refuses a request nobody released; closing or merging the incident rejects its unreleased requests too. See Change control.
• CI/CD pipelines' writes on Kubernetes are changes when their service account runs in a namespace listed in k8s_ci_namespaces (by default flux-system, jenkins, gitlab-runner and tekton). See CI/CD service accounts.
• Tickets name the assignee and who is notified, and an Azure DevOps work item moved to Done, Closed, Resolved or Removed resolves its incident (subscribe the service hook to workitem.updated too). See Ticket systems.
• Maintenance windows can name the Nth weekday of the month (Weeks of the month), and the hours after midnight of an overnight window belong to the day it starts.
• Change requests: backup steps read Automated (platform backup) and the wait for the backup is shown as such; a runbook named by the analysis keeps its commands in the document; section 2.4 shows an estimated blast radius.
• Security posture by domain. Posture, Vulnerabilities, Patching and Backup are separate menu items, and a finding opens on its own page with its resources first. On a scanner rule you can pick which open resources one analysis fixes (In this run). Each EC2 instance or RDS database without a backup opens a Backup finding with the commands that close it. See Security posture.
• SOC 2 / ISO 27001 are phase 2. They are off in every workspace until your platform administrator turns them on, once they are agreed with you: no framework score, no platform checks, no Compliance frameworks (phase 2) card in Guardrails. Security Hub, Defender, Inspector and conformance-pack findings and scores are unchanged.

What you may need to do

• Open platform-check findings (EST-01 to EST-06, LOG-01, CRY-01, ACC-04, MON-01) are resolved on the first scheduler cycle after the upgrade, as a scope change.
• A workspace that set a storm threshold keeps it stored, but it is ignored: grouping uses its own windows, set through the workspace settings (aiops_storm_group_window_s, aiops_storm_spread_window_s).
• To keep full analyses of known issues, turn Shorten the analysis of a known issue off on Guardrails (in the product: /portal/guardrails). To keep the single validation read, set Rounds to 1 on Change safety.
• If your Azure DevOps service hook already sends workitem.updated, an update that changes a work item's state is now a signal: a state change on a work item the platform has not seen opens an incident.
• A storm incident left open by an earlier release is not split any more; resolve it once its services have their own incidents.

0.1.146 — 24 October 2026

Changes from the customer review of 23 October. The releases between 0.1.133 and 0.1.146 are in the release notes.

What changed

• Scanner findings are pulled by default. Every workspace pulls Security Hub and Defender for Cloud findings through its read connections every 15 minutes, whether or not SOC 2 / ISO 27001 scoring is on, and the AWS pull includes Amazon Inspector CVEs. Only a workspace whose owner chose Off keeps it off; one that never changed Scanner sync starts pulling. Every HIGH or CRITICAL CVE arrives as a P1/P2 finding and, while Analyse P1/P2 findings automatically is on, starts one paid analysis.
• Only the findings of your resources. An AWS read connection into an account you share with other workloads takes Only findings on resources tagged (one key=value, such as aiops-managed=true) under Advanced connection settings: the pull then asks Security Hub only for findings on resources with that tag. A value that is not one key=value pair stops that connection's pull with invalid_tag_scope; it never pulls wider. See Set up compliance.
• The change management agent drafts every change request. The narrative sections of the change request document (objectives, requirements, assumptions, prerequisites, the impact and risk rationale, out of scope) are drafted by one change-agent run of at most 8 steps per change request, about USD 0.33 measured. Its plan drafting stays off. See The change management agent.
• The change page is the change request document. It opens with the Change request document card and continues in an order modelled on the template. "Verification" is now Validation plan and "Safety net" is Rollback plan; each back-up and change step under Runbook steps shows the exact reviewed call and the provider's answer. The Scope card lists each resource with its decision, without the action column. A change whose blast radius the estate model reasoned (not an estimate) with nothing lost, nothing also affected and no dependent service reads No negative impact found (— gains only when it only adds), on the change page, the estate map and section 2.4 of the document; section 4 lists each typed step's command.
• Service correlation. "Alert correlation" is now Service correlation in the sidebar and on the incident's L2, and an alert that names no service reads unidentified service, in the triage queue and wherever it was called unmapped.
• Automated triage in the order it runs: dependency map, known issues, cloud health, recent changes, signals, summary, fault domain.
• L5 names its change request (Proposed change — drafted into CHG-…, linked).
• A failed execution is shown on the incident. When a released fix fails before any verdict, the summary reads Execution failed — CHG-… and L5 offers the next steps (feedback, resolve, mark as noise, re-analyse, hand off) with the backout and a link to the change; L5 and the L7 history list failed executions and operators' execution reports beside the fix attempts. Mark as noise is in the incident header, beside Mark resolved.
• Estate map: a service group's network path follows ingress routing from the internet or VPN gateway to the firewall whose network interface a route names. FortiGate deny policies and Palo Alto Networks rules that do not allow are drawn with their action, and Palo Alto Networks rules carry their hit count and last use.
• AWS permission check: a step runbook's permission check asks about the real target with its tags, so on the guided write role it can answer; a target without the aiops-managed=true tag reads missing and a person releases its change.

What you may need to do

• Before the first pull after the upgrade, decide the cost: set a daily cost limit on Guardrails (in the product: /portal/guardrails), set Scanner sync to off where you do not want the pull, give a shared AWS account's read connection Only findings on resources tagged, or set the connection's Pull Inspector vulnerability findings (CVEs) to false.
• Re-run the AWS CloudShell setup for every account it set up (or re-apply the deploy/aws module): the read role gains the Lambda function list and the ECR repository and image reads, and the write role gains patching with AWS-RunPatchBaseline on tagged instances and Reachability Analyzer, which nothing uses yet. Until then the harvest's Coverage lists lambda:ListFunctions as denied. See Set up AWS.
• To keep change requests without the agent's narrative, turn Change management agent off on Guardrails (in the product: /portal/guardrails).
• The first firewall harvest after the upgrade lists the deny rules as added once.

0.1.133

The switches the acceptance-story configuration runs with are now the defaults, and the documentation is published for people and AI agents alike.

What changed

Seven switches are now on by default. A workspace that has not set them gets the new behaviour on upgrade:

• Alerts that name no service wait in the triage queue. An alert with no service after your label mapping opens its own unmapped incident with no analysis, ticket, page or automatic fix until someone maps the source or chooses Analyse; before, it was grouped by alert name or namespace and analysed. This includes Azure Monitor alerts that target only a workspace, Application Insights or the subscription (such as Service Health) and CloudWatch alarms with no resource dimension (billing, account-wide metrics). With the triage queue on, the missing identity labels hold no longer applies: such an alert goes to triage instead. See Unmapped signals.
• A fix that fails its post-change validation reopens its incident one severity level higher (warning → error → critical), and its priority is worked out again.
• An emergency change's post-implementation review is scheduled when the request is submitted. The due date shows at once, and the review stays due even if the change never lands.
• Rolling back the pinned change comes first. When an incident is pinned to a suspected change that can be rolled back, rolling it back is the first recommendation on the incident, in the analysis plan, in the report and on the change request.
• A fix inside a runbook route's operations is a standard change. When a matching pre-approved remediate-… route declares every step of the fix (each operation ticked on Guardrails), the change request is recorded as standard, even at P1. P1 and critical fixes keep the emergency release rules: two approvers and a review.
• The platform's own credential used without a receipt is flagged. A cloud write made with one of the workspace's connection credentials is flagged unauthorized when no platform change, approved action or scanner suppression accounts for it within 10 minutes.
• An unmanaged change re-checks every control it touches. An unmanaged cloud write re-checks every compliance control its resource kind maps to, plus every rule it matched. Each re-check is a read-only cloud probe, so expect more read API calls.
• Roll back a failed cloud fix automatically is unchanged: it stays off until you choose a tier.
• Documentation: the guide is in eight sections, from Get started to What's new, and its home opens with three Quick start tasks; the same pages are published at /help on your installation, each with a Markdown twin, and indexed for AI agents at /help/llms.txt. The MCP server's get_workspace_context returns those links. Insights chat answers workspace owners from the platform guide too.

What you may need to do

• To keep the old behaviour of a switch, turn it off on Guardrails (in the product: /portal/guardrails) (or PATCH /guardrails with <field>: false; null returns it to the default). Each switch row says whether it follows the platform default. For a whole deployment, your platform administrator sets AIOPS_<KEY>=false.
• Alerts from sources that send no service label now wait in Needs you → Triage: add the label at the source, or, on one of their incidents, choose the label on the Unmapped signal — map this source card so the next alert from that source names its service.
• If people in your team make cloud writes with the platform's own connection credentials outside the platform, expect them to be flagged unauthorized; give them their own credentials.

0.1.132 — 17 October 2026

Bug fixes found by reading the documentation against the code, and the onboarding steps a new team was missing. No new setting.

What changed

• The cost cap survives a Guardrails save. The Cost cap & PII patterns card pre-filled an inherited cap as 0, so saving a PII pattern or the SSRF switch wrote 0 — no cap — over the platform default. The field is now empty while the workspace follows the platform default, its placeholder shows the value in effect, it is sent only when you change it, and an emptied field returns to the default. 0 still means no cap. A 21st PII pattern is refused instead of being dropped silently.
• Help text that said the wrong thing was corrected: the cost-cap help says the run stops at the cap and skips the wrap-up; the egress floor and the extra approval gates say a caught call is refused during diagnosis on the default posture; the execution hint names the real checkbox, Allow use for approved plans; a harvest that found nothing says why; a stale approval gate says to stop the run before re-analysing.
• Confirmations before destructive actions: revoking an API token and deleting a chat conversation ask first; revoked and expired tokens are labelled.
• Inputs the server now checks: an invalid schedule cron on Agent behaviour is refused (422) instead of being saved and never firing — and so is a well-formed one that can never fire, such as 0 0 31 2 *; a built-in benchmark for a pillar with no scenarios is refused instead of starting an empty run; a golden-set or dataset upload names the rows it skipped.
• Screens that hid what was true: a connection whose connector type the platform disabled says so; the route editor offers the network mode; the notifications editor offers the golden and rollback events; Agent behaviour, the Test Lab and the x-ray launch dialog list gateway models only for pillars.manage and explain the manual entry otherwise; an incident lists all of its RCA exports, not only those among the workspace's 100 newest artifacts; expired support grants leave member lists and counts; aiopsctl approvals reads the pending approvals in one call.
• Security Hub pull reads Amazon Inspector CVEs on request. The scheduled pull and Sync now asked only for findings with a compliance status, which an Inspector finding has none of, so no vulnerability arrived through the pull. Set Pull Inspector vulnerability findings (CVEs) to true under Advanced connection settings on the AWS read connection (off by default): every sync then adds a bounded read of the Inspector findings over the same window, sharing the 500-finding cap, and the Scanner sync card shows the count per region. Every HIGH or CRITICAL CVE arrives as a P1/P2 finding and, while Analyse P1/P2 findings automatically is on, starts one paid analysis per CVE. GuardDuty findings are not pulled.
• Access and streams: GET /pending-approvals (read by aiopsctl approvals and the MCP tool) masks a credential inside a gated command the way the incident page does; an open investigation event stream ends when the viewer's access is revoked or a support grant expires; adding an account whose support grant has expired seats it for real.
• (platform console) Saving a built-in connector type works; a connector type's key and name are validated; the ops audit log shows each row's target and filters by action family; the retry-exhausted job counter counts the right jobs; clearing every tier of the platform default model map falls back to AIOPS_MODEL_TIERS_DEFAULT.
• Documentation: who runs each installation step, the harvest as a required free step and the x-ray scan as optional, the P1 → emergency → two-approver chain and the ways around it, a rehearsal of one approved fix, ticket route bodies per system, compliance first steps, and the guide screenshots captured again on this release.

What you may need to do

• A pillar whose saved schedule cron is invalid cannot be saved on Agent behaviour until the cron is corrected; the scheduler never ran it anyway.
• API callers: PATCH /guardrails with more than 20 PII patterns answers 400 instead of keeping the first 20; a pillar schedule_cron that is not a valid cron expression answers 422; a new connector type's key must match ^[a-z0-9][a-z0-9_-]{0,63}$ and its name must not be empty (422).
• No schema change.

0.1.131 — 16 October 2026

Bug fixes found by a live test of 0.1.130, plus the recorded walkthrough films in the documentation. No new setting.

What changed

• A ticket that arrived without a link is written back (ServiceNow, Jira). An inbound ticket whose rule posted no url adopted its incident but never received the analysis, and the row offered no Retry. The platform now writes through the workspace's only enabled connection of that system; with two connections, or a link on another host, the row names the real reason and offers Retry. Send test ticket on a disabled route answers 409 instead of filing. A ServiceNow route saved before 0.1.130 closes a merged incident with Duplicate when the instance has that code.
• Changes → statistics count the whole window. The totals and per-actor rows were computed over the newest 2,000 records, so a busy account's "last 30 days" could report 0 unauthorized while denied attempts sat older in the window. They are now aggregated over the whole window.
• EKS Auto Mode housekeeping is not a change. A service's own reconcile loop signed as an assumed role (invokedBy = eks.amazonaws.com) is dropped and counted under dropped; CreateFleet and RunInstances stay. The datasources a pull truncated are shown on the harvest report.
• The Estate map shows stale nodes again, in grey. Since 0.1.111 the map silently dropped every stale or inconsistent node although the legend says they stay visible; blast radius still reasons over the trusted cut only. A scan's Estate card, counts and Turtle download keep the estate the scan produced after the next harvest of the same connection.
• Documentation: the recorded walkthrough films (15 workspace, 11 platform) are embedded with their transcripts, each captioned with the build it was recorded on; italics and level-4 headings render; one clear button on the docs search; the seven set-up guides are self-contained and no longer stamped with a version.

What you may need to do

• One additive column (xray_scan.estate_counts); automigrate adds it. Upgrade the control plane and private-network agents together.
• Outside AWS writes harvested before 0.1.130 keep the before-state note they were stored with and are not re-read.
• (platform console) The image is about 390 MB larger because of the embedded films.

0.1.130 — 15 October 2026

What changed

• AWS Config before-states for outside changes. Up to 0.1.129 every AWS write harvested from CloudTrail was listed with AWS Config holds no configuration item for this resource around this write, even with config_history: true and the recorder on, so no outside AWS change ever had a before-state, a diff or Draft revert. The platform now reads the capture times Config returns, going back up to 28 days; every read still counts against the 50 Config reads per connection per pull.
• EKS Auto Mode nodes in the estate map. The harvest, the touched-scope read of a security-group change and the probable-cause attachment read now ask EC2 for managed resources. After the first harvest on 0.1.130 these nodes appear typed, with their subnet and security-group relations.
• Security-group rules in the map follow a complete read. One authorize now writes one rule; a complete read of a group makes its rule edges exactly what AWS returned, so a revoked rule no longer lingers on the map.
• Fewer change-driven re-reads. SSM agent heartbeats and reports and AWS Config rule verdicts are no longer recorded as estate changes; SendCommand, StartSession and PutParameter still are. The 500-event limit per connection per pull now counts kept events, and reaching it marks the pull truncated.
• The daily harvest runs daily. A workspace with many change-driven re-reads ran the scheduled harvest on every tick; it now finds the last scheduled one directly.
• ServiceNow and Jira tickets. Check reads ServiceNow's resolution codes from the incident form when sys_choice is refused, so the Duplicate code is found for merged incidents. Send test ticket gives the create 20 seconds and closes what landed when the answer is lost. An escalated incident whose own adopted ticket is resolved or closed in ServiceNow or Jira resolves when nothing else is firing; with Keep an incident open while its fix waits for a decision on and a fix waiting, it stays escalated and its timeline says so. The note written to your ticket reads AIOps analysis — incident resolved in AIOps at …. A ticket reopened soon after the platform's note is a new signal.
• Documentation: seven set-up guides (change windows and rollback, security posture, alert sources and intake rules, compliance, AI models and prices, notifications and tickets, write connections) and a "How far to trust the map" section in the knowledge chapter.

What you may need to do

• No schema change, no new setting and no new permission: the EC2 and AWS Config reads use the actions the bundled roles already grant.
• The first harvest after the upgrade can list EKS Auto Mode nodes as added and report a security group's relations as changed once; a change request reviewed before that harvest whose removed relations change needs a fresh review.
• Outside AWS writes harvested before the upgrade keep their old before-state note and are not re-read; such a write has no Draft revert and is reverted where it was made.
• Upgrade the control plane and private-network agents together.

Full release notes

The complete notes for every release since 0.1.89, with the release tags and the upgrade notes per version, are in Release notes by version.

Next steps

• Next: Release notes by version
• All What's new pages
• Documentation home