Release notes 0.1.167
29 October 2026: A fix release.
Release notes · Updated 2026-10-29 · Describes release 0.1.173
0.1.167 — 29 October 2026
A fix release. An approved change with no incident behind it runs at its window again, a patch run is graded on what the platform reads after it, an incident waiting for a runbook's fix stays open, a ticket waiting for information gets nothing more written on it, an out-of-memory pod leads its incident, the automation in your AWS account reads AWS Health without a support plan, and Amazon Inspector findings that reach Security Hub late are no longer missed. A change whose scheduled release is refused goes back to waiting for approval, a run that leaves some resources out is still offered its certified runbook, and the AWS read role can read a Lambda function's runtime and aliases. No schema change, no new route, setting or audit action. To upgrade, re-run the AWS setup (below), and update the function in your AWS account if you run the automation there (below).
Changes and their checks
- An approval no longer goes stale on its own vote. Approving or scheduling a change with no incident behind it (a compliance or patch change, for example) adds the services its impact report names to the change. Those services were also part of what the approval was bound to, so the vote changed the change it approved, and the release at the window refused it as changed since approval. The services added this way are still shown on the change and used by its verify, but are no longer bound into the approval. Approvals already waiting are unaffected.
- A patch run is graded on its validation plan. A change with no incident behind it, such as a scheduled patch run, is now checked against the checks listed in its validation plan, as an incident's fix already was: the platform reads the patch state from Patch Manager and that the instance has its original security groups back. When those reads pass, the change is marked cleared with no AI check (behind the existing typed-check switch on Guardrails). When a check is left to the AI, it sees only the listed checks and no web search, and a failed platform read decides the verdict whatever the AI says. Before, a clean patch run could be marked still present, because the AI also graded the mid-run check that only the isolation group is attached, which is false once the groups are restored.
- The isolation group allows outbound TCP 80 as well as 443. The runbook guide now says the isolation group needs both ports (443 for the SSM agent and HTTPS repositories, 80 for plain-HTTP mirrors such as Ubuntu's EC2 mirrors), matching what the platform's check before the swap already accepted.
- A refused scheduled release puts the change back to waiting for approval. When a change's scheduled release fires as a person who no longer holds the approve permission, the release is refused, that person's vote is dropped and the change waits for approval again. The refusal is recorded on the change's audit as a refused release, as it is when a person clicks. Before, the refusal also undid the dropped vote: the change kept reading approved, and the old vote counted again once the person had the permission back.
- A run that leaves resources out is offered its runbook. When a person leaves some of an incident's resources out of a run, the fix plan is now offered the certified step runbook, bound to the first resource the person kept. Before, the runbook was bound to the incident's first alert whatever was left out, the review refused it, and a fix only a runbook covers (a Lambda runtime upgrade, for example) ended with no typed operation covering it.
Incidents and tickets
- An incident waiting for a runbook's fix stays open. With Keep an incident open while its fix waits for a decision on (the default), the quiet-window close now also skips an incident whose proposed fix matches a runbook that is not certified at its current revision. Before, only a certified runbook's match held it, so an incident could close while its fix still waited for a person.
- A ticket waiting for information gets only its question. A ticket the platform holds because required fields are missing gets nothing more written on it when a person resolves the incident (single or bulk resolve, merge, retry or the sweep). Before, resolving posted a second comment, No finished analysis was recorded.
- An out-of-memory kill leads its incident. When one detection poll sees a pod killed for running out of memory that then crash-loops, the incident is opened by the out-of-memory alert (R32) and the crash-loop alert (R31) joins it. Before, the crash loop opened the incident and the out-of-memory alert, the actual cause, was suppressed.
Inspector findings
- Amazon Inspector findings that reach Security Hub late are read. Inspector findings arrive in Security Hub up to a few hours after their update time, and Security Hub cannot filter on arrival time. The scheduled pull read them in the same 35-minute window as the control findings, so a finding that arrived after its window had passed was never read. The Inspector read now starts 6 hours earlier than the control read. In those extra 6 hours a finding that is already open in the register is skipped, so re-reads never fill the per-pull cap or cut another region's control read.
Automation in your AWS account
- AWS Health without a support plan. When the AWS Health API needs a Business or Enterprise support plan, or
health:DescribeEventsis denied, the function now reads the public AWS Health Dashboard feed, as the platform does. Either source counts as the AWS Health read, so the platform can pause its own poll for it; the function needs internet egress for the feed. When neither answers, the run reports both errors and the platform keeps polling. - Each cluster that read is reported. The run now names every Kubernetes cluster whose read succeeded, even when another failed (before, one failed cluster meant none was named), and the run output lists
clusters_coveredand says when Kubernetes rules are on but no cluster is configured. - These take effect when you update the function in your account to this release's package.
AWS setup
- The read role reads a Lambda function's configuration and aliases. The guided read role (and the
deploy/awsread policy) now grantslambda:GetFunctionConfiguration,lambda:GetAlias,lambda:ListAliasesandlambda:ListVersionsByFunctionin the connection's region, so the agent sees a function's current runtime and alias before it proposes a Lambda runtime upgrade. The guided role is not grantedlambda:GetFunction, because that read also returns a link that downloads the function's code; thedeploy/awsread role already had all five throughReadOnlyAccess. - Upgrade: re-run the AWS setup. Until then the guided role answers those reads with
AccessDeniedException. Select Leave out account-wide settings (shared account) again if you used it.