| Agent | agents/alert-analyser/ |
| Schema | incident_management.incidents (Postgres) |
| Status | Live, verified end-to-end. RCA/Action agents not yet built (consumers pending). |
| Generated | 3 July 2026 |
When alert-analyser's sync cycle classifies an OpsGenie alert as "genuine," the system synchronously creates or updates a ticket in a shared incident_management Postgres schema. This schema is designed to be polled by future RCA and Action agents, giving them a durable, deduplicated queue of real incidents to work — independent of OpsGenie's own state, noise, and duplicate open/close event pairs.
Dedup key is alert_id (OpsGenie's alert ID). On each sync, for every genuine alert:
alert_id → create new ticket, status = ESCALATED.updated_at, increment recurrence_count.related_ticket_id pointing to the prior ticket.alias (fallback id), keeping the record with the latest createdAt. Same incident firing multiple open/close events in one sync no longer creates duplicate ticket-loop iterations.status field is closed or resolved are skipped entirely, even if classified genuine. Known limitation — see Future Work Tracker: the status field alone is unreliable; many source tools update the alert's message/title instead.After ticket creation/update, a second pass runs on every sync to detect tickets whose underlying alert is no longer open+genuine, and reconciles their state:
| Current Ticket Status | Alert No Longer Open+Genuine | Action |
|---|---|---|
ESCALATED | Yes | Auto-set status = RESOLVED, resolved_at = now() (nothing was in-flight, safe to close) |
INVESTIGATING / RCA_COMPLETE / REMEDIATING | Yes | Set resolved_externally = TRUE — flags that the alert self-cleared mid-pipeline, without overwriting agent-driven status (preserves whether the pipeline's work mattered) |
RESOLVED / MANUAL | N/A | No-op — already terminal |
| Column | Type | Purpose |
|---|---|---|
| id | UUID (PK) | Ticket identifier |
| alert_id | TEXT | OpsGenie alert ID (dedup key) |
| alert_signature | TEXT | Reserved for future RAG pattern matching |
| status | TEXT | ESCALATED / INVESTIGATING / RCA_COMPLETE / REMEDIATING / RESOLVED / MANUAL |
| priority | TEXT | P1–P4 (from OpsGenie) |
| title | TEXT | Alert message/alias, truncated |
| alert_payload | JSONB | Full original alert object — the data contract for RCA/Action agents |
| rca_findings / action_outcome | JSONB | Reserved for RCA/Action agents (not yet populated) |
| recurrence_count | INTEGER | How many times this alert has re-fired while ticket stayed open |
| related_ticket_id | UUID (FK, self) | Links a new ticket to a prior resolved/manual ticket for the same alert_id |
| resolved_externally | BOOLEAN | True if the ticket was reconciled/closed by the sync process rather than an Action agent |
| detected_at / escalated_at / rca_completed_at / resolved_at | TIMESTAMPTZ | Lifecycle timestamps |
| created_at / updated_at | TIMESTAMPTZ | Row bookkeeping |
Priority-based response-time targets, applied to the Aging panel and per-ticket breach flag (proposed policy — not yet formally adopted org-wide):
| Priority | Definition | Target Response | Target Resolution |
|---|---|---|---|
| P1 — Critical | Service outage, major business impact | 15 min | 2 hours |
| P2 — Major | Major functionality degraded, no workaround | 30 min | 4 hours |
| P3 — Minor | Limited impact, workaround available | 60 min | 8 hours |
| P4 — Internal | Minor impact, non-urgent | 240 min | 3 business days |
Implemented Target Response is applied today as the SLA breach flag on the Aging panel and kanban lanes. Target Resolution is not yet used (no Action agent exists to actually close tickets on a timeline).
| Category | Definition |
|---|---|
| Auto-Resolved | status=RESOLVED and resolved_externally=FALSE — closed by reconciliation because the source alert cleared before any agent touched it |
| Action-Resolved | status=RESOLVED and resolved_externally=TRUE — Placeholder currently indistinguishable from resolved-mid-pipeline; needs a real Action agent to set this deliberately |
| Manual | status=MANUAL — closed by a human |
recurrence_count, surfacing alerts that keep re-firing while a ticket is open.Four columns — P1-CRITICAL, P2-HIGH, P3-MEDIUM, P4-LOW — each showing its SLA target as a subtitle, ticket cards sorted oldest-first, capped at 6 visible with a "+N more" indicator. Cards show status dot, short ID, time-since-escalation, title, alert ID, recurrence badge (if >1), and a red border + "⚠ SLA" badge when the SLA has been breached.
| Endpoint | Purpose |
|---|---|
GET /dashboard/incidents | Aggregated KPI data: pipeline_flow, aging_buckets, aging_longest_wait, resolution_ring, recurrence_signal, sla_breach |
GET /dashboard/incidents/list | Individual tickets (optionally filtered by status/priority), including sla_breached and resolved_externally, sorted oldest-first — powers the kanban lanes |
GET /dashboard/period-summary | Row 2 "Alerts in Period" KPI cards; extended this session with new_incidents_count / recurring_incidents_count sourced from the incidents table (true new-vs-recurring split, replacing the previously misleading "new genuine" alert-event count) |
GET /dashboard | Main dashboard stats; also extended with the same new/recurring incident fields for the Genuine Alerts tab |
See the companion Future Work Tracker for the full, current list of flagged gaps and their code locations.