Incident Response — Agentic MTTR Demo

INC17837977859814

P1newai_assisted

orders-service reporting connection pool exhaustion against orders-db

Assembled Context — bounded to last 30 minutes
Rolling logs
Recent commits
(none in lookback window)
Similar past incidents
(none found)
Diagnosis Agent
ran in parallel
The orders-service's HikariCP connection pool is capped at 100 connections, which are fully utilized, causing request timeouts and 504 errors despite the database having available connections.
  • [orders-service] ERROR HikariPool-1 - Connection is not available, request timed out after 30000ms
  • [orders-service] WARN active connections 100/100
  • [orders-db] INFO max_connections 200, current 198
  • [orders-service] ERROR 504 Gateway Timeout on /v1/orders
Assessed: P2 / application
Self-reported confidence: 95% (audit-only — not used by the gate)
openai/gpt-oss-120b · 1408ms
Severity / Routing Agent
ran in parallel
P2 / database
Routed to: orders-team
The orders-service is experiencing connection pool exhaustion despite the underlying database having spare capacity, indicating a configuration or contention issue within the service's interaction with the database. This is causing 504 errors on critical order-processing endpoints, representing a significant degradation for users.
Self-reported confidence: 95% (audit-only — not used by the gate)
gemini-flash-lite-latest · 998ms
Scenario Matcher
deterministic, pre-LLM
Connection pool exhaustion
Connection pool exhaustion on the application tier is typically cleared by restarting the affected service to release stale connections.
Match score: 86% · Recommended action: restart_service
Matched tags: connection pool, exhaustion, timeout
Confidence Gate

Computed from 4 measurable signals — not the model's self-reported confidence.

Severity match rate50%
x
Runbook coverage86%
x
Data completeness33%
x
Recency50%
x
Computed confidence (v1)60%
Auto-execute threshold: 75%