Release notes 0.1.184
2 November 2026: Finding pages move to /portal/findings/<id>.
Release notes · Updated 2026-11-02 · Describes release 0.1.184
0.1.184 — 2 November 2026
Findings and alerts
- Finding pages move to
/portal/findings/<id>. Every link the platform writes (lists, Needs you, change pages, notifications, the change request document) uses the new address. Old/portal/compliance-findings/<id>links still open: they redirect to the new page. - A finding closes when the scanner clears it. An escalated finding whose alerts all come from cloud scanners now closes by itself once the scanner reports every one of them passed or resolved (audit
incident.resolved, "auto-resolved: the scanner reported every finding of it passed or resolved"). It stays open while a change for it waits for a person or is running. - Automatic analysis has a burst limit. A large scanner pull can no longer start hundreds of automatic analyses at once. At most 10 automatic analyses run per workspace in any 15 minutes (Burst limit on Guardrails, in the automatic analysis of P1/P2 findings card; 0 = no limit). A finding past the limit waits with the reason "automatic analysis paused: burst limit reached for this workspace"; use Analyse, or let the catch-up sweep pick it up when that is on.
- An alert labelled only with an EC2 instance id finds its service. The lookup no longer stops when the same id also names the instance's Systems Manager record.
- The lookup for an alert with no service shows its steps. The incident timeline now says which read-only connection was checked and what it found: found and joined, seen but with no owner (waiting for a person), or not visible to any read-only connection (needs a person). The hourly re-discovery for a held alert appears on that alert's incident as well.
- Who changed it. A finding's header names the person or session of the captured change straight away, and says "loading…" rather than "actor not recorded" while the page is still reading it.
Changes and risk
- An observed change names its session. A change made outside the platform shows the principal and the session that made it in the page head.
- The automatic re-analysis after a failed fix has its own label. It reads "automatic re-analysis" on the incident and "Re-analysed after a fix was rolled back" on Agents activity, no longer as if a person pressed Re-analyse.
- A risk request nobody decided expires. A requested risk exception still undecided when its request window ends leaves Needs you and shows as expired in the risk register (audit
risk.request_expired). - Records closed by hand do not block automation. A record closed by hand without a validated fix no longer counts as "a fix that did not hold" when the platform decides whether a runbook may run on its own. It still counts as an occurrence.
Monitoring and dashboard
- Proactive monitoring card. Settings › Synthetic checks has a new card for the detector that runs in your AWS account: live or stale, last run, runs in the last 24 hours, metrics read, resource × rule pairs judged, breaches, and its rule-pack version next to the platform's. The detector (version 0.1.1) now sends these numbers with each run; an older detector shows them as "not reported" until it is redeployed. Data sources › Built-in detection links to the card.
- Alert noise per month counts only incidents that came from alerts. A month can no longer show more incidents than the alerts that opened them.
Layout and look
- Dark is the default look. A workspace or person that has not chosen a theme, and the sign-in page, open in the dark look. An explicit choice still wins.
- Option-5 layout on the remaining pages. Quick start, Problems, Report, Usage & billing, the Estate pages, Chat, Estate x-ray, Lakehouse, Knowledge base, Test Lab, Feedback and the remaining Settings pages use the same page frame as the rest of the console.
- Wording. Server-written text says "finding", not "finding incident", and the Needs you link for unmapped signals matches its group name.
Documentation
- Operator runbook. A new runbook for the people who run the platform day to day: roles, the daily routine, handling an incident and a finding, changes and runbooks, safety controls, connecting sources, and the platform team's procedures. Sections 1–8 and 16 are the day-to-day part.