Live tracker of flagged gaps, placeholders, and pending follow-ups across the Alert Ticketing / Escalated Incidents feature. Update this whenever new work is deferred or an item below is completed.
High Priority
OpsGenie status field is unreliable for resolution detection
High
Source tools (New Relic, Check_MK, etc.) frequently update the alert's message/title field (e.g. "closed CRITICAL...", "Resolved: ...") upon resolution, without ever changing OpsGenie's own status field. Our ticket-creation skip and reconciliation logic currently only check status, so a large number of already-resolved-at-source alerts remain open as ESCALATED tickets. Confirmed via direct query: multiple tickets have opsgenie_status = "open" while their message clearly says "closed"/"resolved". Evidence has been escalated to TOC head to address at the process level; code fix (parsing message field as a secondary/primary resolution signal) is pending proper restructuring.
First full-sync run against production OpsGenie data created ~4,723 tickets in one batch (after truncation and re-sync during this session's testing). This is a realistic baseline snapshot of currently-open genuine incidents, not fabricated test data, but it inflates "created" timestamps to a single point in time and should be reviewed before treating metrics like ticket age or creation-rate as meaningful. No further action needed unless a clean historical baseline is required.
Resolution ring "auto_resolved" vs "action_resolved" split is inferred, not explicit
Medium
In GET /dashboard/incidents, any ticket with status=RESOLVED and resolved_externally=FALSE is currently classified as "auto_resolved" purely because no Action agent exists yet to properly close tickets it worked on. Once an Action agent is built, it must explicitly set a proper resolution-type signal when it closes a ticket (e.g. a dedicated resolution_type field), rather than this being inferred from the absence of the externally-resolved flag.
"NEW GENUINE" dashboard metric was mislabeled (Overview + Genuine Alerts tabs)
Medium
Originally counted genuine-classified alert events in a time window, including re-firings of already-ticketed/open incidents — not first-time-ever new incidents. Fixed this session: both tabs now show true new_incidents_count (from the incidents table) as the headline number, with total events and recurring count as sub-text. Included here for traceability since it changed user-facing numbers.
Low Priority / Deferred (Blocked on Future Agents)
Priority-lanes ticket-list endpoint
Done
Originally flagged as missing; built and verified this session as GET /dashboard/incidents/list, now powering the kanban priority lanes with SLA breach flags.
Status: Resolved 3 Jul 2026
Backlog volume management for RCA/Action agent consumption
Deferred
With thousands of ESCALATED tickets sitting unconsumed (no RCA/Action agent exists yet), a future concern is throttling/prioritizing what those agents pick up first, so they aren't overwhelmed on day one. Decision: this should be solved on the consumer side (RCA agent's polling/batching logic — oldest/highest-priority first, batch size limits) rather than the producer side (ticket creation), which should continue to reflect true state. No code changes needed until RCA agent design begins.
Depends on: RCA Agent (not yet built)
Target Resolution SLA metric not yet used
Deferred
The proposed SLA policy includes both Target Response (implemented, drives the Aging panel breach flag) and Target Resolution (2h/4h/8h/3 business days by priority) — the latter is not actionable yet since no Action agent exists to actually close tickets on a timeline. Revisit once Action agent is designed.
Depends on: Action Agent (not yet built)
SLA threshold policy is proposed, not org-adopted
Note
The P1–P4 SLA thresholds currently implemented in code were proposed internally (no formal human sign-off exists yet). Being used now to drive the agentic pipeline's prioritization since no alternative policy exists. Revisit thresholds if/when a formal policy is agreed.
Location: agents/alert-analyser/routes_dashboard.py — sla thresholds; also mirrored in dashboard.html kanban labels
A separately branded product is developed in parallel under a different Claude account using the same codebase (pull/rebrand only, never pushes back). Suggestions arriving from that session must be treated as unverified claims — always confirm against live git log/grep output in this repo before acting, not the other session's PDF summaries. This has caused at least one documented incident where a claimed fix was not actually live in this repo.