# Release notes 0.1.153

> 25 October 2026: Three changes from the customer reviews of 22 and 23 October: a ticket sent in must name the five fields the platform writes on its own tickets, an EC2 instance can be patched by a…

_Release notes · Updated 2026-10-28 · Describes release 0.1.164_

## 0.1.153 — 25 October 2026 {#0-1-153-25-october-2026}

Three changes from the customer reviews of 22 and 23 October: a ticket sent in must name the five fields the platform writes on its own tickets, an EC2 instance can be patched by a step runbook that backs it up, isolates it and puts its security groups back, and built-in detection raises degradation, Kubernetes state, scheduled maintenance and provider issues where nobody created an alarm. Also: the known-issue relevancy says when the prior fix did not hold. Schema, additive: two JSON columns on `detectionstatus`. New settings `ticket_required_fields` and `aiops_patch_findings`; new read-role and write-role permissions (see the [upgrade row](/help/ops-upgrade-and-verify.md)). No new route.

- **Tickets that come in must name five fields:** a Jira, ServiceNow or Azure DevOps ticket sent in must name **service, severity, priority, assignee and notify** — what the platform writes on every ticket it files. The adapters read each system's own fields, `field:value` labels or tags and `Field: value` description lines (`TBD`, `n/a` or `-` name nothing; a stated severity only ever raises the one the ticket's own fields give). A ticket missing any is **held**: it opens its own incident in the triage queue (chip **Triage**, the incident wears **awaiting info**), is never grouped and starts no analysis, notification or automatic fix; the row says what was asked for and links the ticket. About a minute after it arrives AIOps posts one note on the ticket through the workspace's **Ticket system** route (a Jira comment, ServiceNow work notes, an Azure DevOps history entry) listing the missing fields, where that system takes each and the values it accepts — once per ticket ever, only for a ticket created within the hour, at most 20 per workspace an hour, never on a ticket the platform filed itself (**Asked on the ticket for missing fields**, audit `ticket.info_requested`). The update that names them all resolves the held incident quietly and lets the ticket open or join its service's incident (**Ticket named its missing fields — moved on**, audit `ticket.info_received`); **Analyse** investigates a held ticket at once. The ticket exemption from the unmapped hold is gone. The list is `AIOPS_TICKET_REQUIRED_FIELDS` (a JSON list, default all five), narrowed or extended per workspace with `ticket_required_fields` (`[]` = none of the five; a ticket naming no service still waits while `aiops_unmapped_triage` is on, the default). Jira has no severity or notify field: a `Severity:` / `Notify:` line or label names them; an Azure DevOps work item names its service and who to notify with a `service:` / `notify:` tag or line. The ServiceNow inbound business rule template now posts severity, impact, urgency, assignee, assignment group and watch list; who they name is not kept in the alert's raw payload, only that they are named. The ticket metric gains `op="ask"`.
- **The EC2 patch runbook:** three operations for step runbooks only — `aws.ssm.patch_baseline` (`AWS-RunPatchBaseline`, `Operation=Install`, the default reboot; `BaselineOverride` and `InstallOverrideList` are refused at compile and again before the send), `aws.ec2.isolate` (records each network interface's security groups, checks the isolation group — same VPC, no inbound, outbound TCP 443 and 80 at most — and reads Patch Manager first: a node with nothing missing is not isolated, and the run stops with nothing to roll back) and `aws.ec2.restore_sgs` (puts the recorded groups back). The quality check requires an image before a patch and a restore after every isolation on the same target. The analysis never proposes these operations; a fix gets them by naming a runbook that carries them. A run that stops between the isolation and its restore runs the restore anyway as a compensating receipt, except while agents are paused, the licence blocks runs or the patch may still be installing: the change then says the instance is still isolated, its rollback plan leads with the restore lines and the Timeline reads **Instance left isolated — put its groups back** (audit `change.isolation_left`, notified on *escalate*). A run cut off by a control-plane restart is reported the same way two hours after its last step, or at once when a person reconciles it. **Roll back** restores the root volume from the image and then puts the recorded groups back. The demo workspace gains the disabled example route *EXAMPLE: EC2 patch with backup and isolation* on a disabled placeholder write connection, selecting the platform's own patch finding; other workspaces create it from the request in the help chapter *Runbooks and automatic fixes* (The EC2 patch runbook), named `remediate-…` so it can make a fix standard. Not yet run against a live instance: tested against simulated EC2 and Systems Manager answers.
- **Patching findings from the Patch Manager read:** with `aiops_patch_findings` on (the default; a workspace override), the daily Patch Manager read opens a **Patching** finding for each non-compliant Systems Manager managed node in the tag scope (source **Patch Manager (platform read)**, control `PATCH.COMPLIANCE`, all of them one incident; HIGH (P2) with a missing critical patch, else MEDIUM (P3)), unless Security Hub's SSM.2 already holds that node open. The finding carries the commands that close it. Only a read that covered the account and region in full clears one; a node that leaves the tag scope is named in one `compliance.patch_out_of_scope` audit row; off clears every open record. With no patch-age rule set, the **Patch compliance** card shows a 40-day rule as an example, not a default, with the nodes it would flag; it changes no score.
- **Built-in detection raises degradation and state:** twelve rules, R26–R37. R26–R28 compare an Application Signals service's fault rate and latency and an ALB's target response time with their own baseline (the 95th percentile of 5-minute values over 7 days, read once a day, 3 of 3 × 5 min above it: a spike shorter than 15 minutes raises nothing). R29 and R30: Container Insights' failed EKS nodes and pod restarts. R31–R34 read every enabled read-only kubectl connection each poll: a container in CrashLoopBackOff, an OOMKilled container, a pod Pending over 10 minutes, a node not Ready over 5 minutes — one alert per workload, its `resource_id` the estate inventory's. R35 and R36: EC2 instance events and RDS pending maintenance with a date, read hourly, an `info` (**P4**) incident on the resource itself unless criticality or blast radius raise it — our proposal while incident or notice is still an open question. R37: an open AWS Health issue (the Health API, or the public dashboard without a Business, Enterprise On-Ramp or Enterprise support plan) for a service and region where the estate has an in-scope resource of that service is one **P2** incident per issue, `service` `aws-<service>-<region>`; a built-in `error` alert is now analysed, ticketed and notified like a critical one. The card shows an **Other reads** line per cluster and account. New metrics `aiops_detection_episodes_total` and `aiops_detection_reads_total`. Not yet run against a live account: the new readers were tested against simulated CloudWatch, Kubernetes, EC2, RDS and AWS Health answers, as was the ticket question against simulated Jira, ServiceNow and Azure DevOps.
- **New rules start in shadow:** on a workspace already armed, each new rule watches in shadow from the first poll it covers something, for the workspace's shadow period (24 hours by default): what it would have fired is listed, the rule table says *New rule: shadow until* and when, and the rule arms itself when the period ends. **Arm now** arms them at the next poll. Stored per workspace in `detectionstatus.rule_since`; the baselines in `detectionstatus.baselines`.
- **The relevancy says when the prior fix did not hold:** when the prior incident's verified last-known-good record is skipped because the same fix did not hold twice in the problem window, triage step 2 read *incident … with this key was resolved, with no verified fix record*. It now reads *its last fix did not hold N times in 30 days — no fast path*; the level stays 70 %.


## Next steps

- Next: [Release notes 0.1.145 to 0.1.152](/help/release-notes-archive-1.md)
- [All What's new pages](/help/what-s-new/llms.txt)
- [Documentation home](/help/)