I make incident response work the same no matter who is on call.

Where I ran into them

• 5 yrsArmy Officer in charge of network support for military operations and a 24-hour surveillance network, in a country under armistice
• 24/7/365IBM Supported a global SOC run around the clock by teams across time zones

1. ProblemFollow-the-sun teams need two clocks in sync: the service's, and every office's.What I builtEverything in UTC, with each team's local time and offset on top.

   How it works

   • Every timestamp is stored and shown in UTC.
   • The top strip turns it into each region's local time and offset, marks the viewer's region, and counts down the current shift.
   • Shifts are defined in one file (APAC 00–08, EU 08–16, US 16–24 UTC).

   See it in the console: Hand off ↓
2. ProblemCustom detection rules and metrics go stale, lose their history, and nobody knows which are still used.What I builtA Git repository as the single source of truth: edits open a PR from the console, and every metric shows where it is used.

   How it works

   • Alert rules, SLO rules and runbooks live in a Git repository. Edits in the console open a pull request, and apply after review, merge and the GitOps sync.
   • CI checks that every alert has a runbook (53 of 53).
   • The metric inventory reads metric names from every rule and dashboard, and marks each metric as in use, unused, or broken (referenced but not collected).

   See it in the console: Detect ↓
3. ProblemWhen the on-call person changes, so does the quality of the response.What I builtRunbooks for every alert, and a Kagent-based AI agent that briefs the situation and the next steps.

   How it works

   • When an incident is declared, the agent reads the incident, its runbooks and live metrics.
   • It writes a briefing: situation, impact, likely cause with confidence, a severity suggestion, and next steps tied to runbook steps, each with a query to run in place.
   • Changes run only after the incident commander approves; the agent can't change the cluster itself. Kagent in the lab, the same tools built in for the public demo.

   See it in the console: Respond ↓
4. ProblemHandoff quality varies, and the next shift ends up calling the last one.What I builtA fixed handoff format that the incoming shift acknowledges.

   How it works

   • The outgoing shift in one view: each incident's states on a timeline, plus alerts, deploys and changes.
   • What got worse and by how much, and a card per open incident with its next step and a note.
   • Written → handed over → acknowledged by the incoming shift.

   See it in the console: Hand off ↓
5. ProblemIt's hard to see a service's state at a glance.What I builtEach service with its resources and current state, colour-coded.

   How it works

   • One topology file defines every component and link.
   • The map colours each one by state. Selecting one shows why, and what breaks downstream.
   • A banner shows whether alerts are arriving at all.

   See it in the console: Detect ↓
6. ProblemIncidents and alerts arrive at the same time.What I builtA priority score that suggests what to handle first, and correlated alerts merged into one incident.

   How it works

   • Each alert is mapped to a component. It joins an open incident that has an alert firing on the same or a directly linked component; otherwise it starts a new candidate.
   • Probable cause: the member the others depend on.
   • Score = SLO budget at risk + downstream impact + age + trend, with the breakdown one click away. The incident commander can merge candidates by hand.

   See it in the console: Triage ↓