Repository navigation
Conversation
…n and the count query An audit log detection is a managed alert rule with signal type audit: N or more matching events arrived in the last W minutes. This adds the wire schemas and endpoints on the audit trail API, the nullable audit_filters_json column on alert_rules, and auditTrailCountQuery, which counts distinct event ids by IngestedAt and bounds OccurredAt so partitions prune.
…ents A detection is a hidden alert rule with signal type audit, written only through the audit trail API by callers who hold audit_log:read. AuditDetectionsService owns the rule row the way an SLO owns its burn-rate rule: destinations and the name are checked under the org's alert rule lock, an edit ends the tick's claim, and a delete takes the rule's state, deliveries and incidents with it. The evaluator counts the events that arrived in the rule's window through AuditTrailService.count. A count is a fact even at zero, so an empty window is healthy and resolves, and a count that could not be read is an evaluation failure that leaves an open incident open. Notifications carry the count as their detail and never an event.
The rule fields and the row read back; the detections service over PGlite (create, list, update, remove, the cap, an unknown destination, a taken name, another org's ids); the count query through the fake warehouse; a scheduler tick that stays healthy below the count, opens at it, resolves below it and holds an open incident while the count cannot be read; and the routes, where a caller without audit_log:read is refused on every endpoint.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
 |
This comment has been minimized.
This comment has been minimized.
![maple-review-bot[bot]](https://avatars.githubusercontent.com/in/4108169?s=60&v=4){kind=small}
… who can open it Every member can read an incident, and the audit log needs audit_log:read. A member who followed the link was sent home with no explanation. The note now says only org admins can open the log, and the link shows for them.
Maple review🟢 Confidence 10/10 · safe to merge. Detections are org-scoped, admin-gated and covered by service, HTTP, evaluator and scene tests; the earlier wrong-link defect is fixed and pinned. Adds audit log detections: an
Before merge
Fixed since the last review
|
Fourth layer of the unified audit log, on top of #2530: detections. An org admin can alert on the audit log.
What a detection is
"N or more events matching these filters arrived in the last W minutes." It is an alert rule of a new managed signal type,
audit, so it gets the alert pipeline as it is: incidents, severities, destinations, silences, the Alerts hub inbox.It is managed the way an uptime monitor's or an SLO's rule is. It cannot be created, edited or listed through the generic alert rule APIs, the alert editor, the MCP tools or the infrastructure-as-code provider. It is written only through new endpoints on the audit trail API, and those need
audit_log:read, which only org admins hold.What it may and may not carry
Alert rules and incidents are synced to every member's browser and sent to shared destinations, so a detection is built to hold nothing a member may not see:
What a member does see: the detection's name, its threshold and that it fired.
How it counts
IngestedAt), not when they happened, so an event a provider delivers late still alerts.OccurredAtis bounded to a week before the window so partitions prune.Changes
auditinAlertSignalTypeandMANAGED_SIGNAL_TYPES;AuditDetectionFilters; the detection wire schemas and four endpoints under/internal/audit-trail/detections.alert_rules.audit_filters_json(migration20261112150508_alert_rules_audit_filters).auditTrailCountQuery, routed to the managed warehouse like the list query.AuditDetectionsService(list, get, create, update, remove; 50 per org; destinations and the name checked under the org's alert rule lock),AuditTrailService.count, and a branch inAlertsService.evaluateRulebeside the other managed types.audit_log:read; each change is recorded in Maple's own audit log asalert_rule.created/updated/deleted.audit: labels, the v2 read-scope switch, the incident page, the iOS formatter and the generated iOS OpenAPI file, the webhook reference.There is no page for this yet. The Detections page in the Security hub is the next layer.
Worth knowing before merging
/v2response that contains anauditincident.anomalyandslo_burn_ratehad the same exposure when they were added. Nothing creates anauditrule until the page ships.Verified
AlertsService.audit.test.ts, 56 tests; 25 alert, audit and anomaly files, 342 tests; the service against PGlite covers create, list, update, remove, the cap, an unknown destination and a duplicate name.AlertsService, 62.gen:anticipated-errors:check,ios:openapi:checkandui:patterns:checkare up to date.oxlint -c .oxlintrc.effect.jsonis clean on the changed files.bun typecheckpasses, 57 of 57.Not verified: the Swift change is not compiled. The count query has not run against a real ClickHouse, only compiled and decoded through the fake warehouse.
Open in [code]smith · Need help on this PR? Tag
@codesmith-botwith what you need.