Chronicle: AI-Native Incident Response Platform

AI-native incident command center with persistent memory — deduplicates alerts, recalls past fixes via RAG, auto-escalates SLAs, and drafts postmortems so teams stop solving the same incident twice.

Comment

Inspiration

Every engineering team has lived the same 3am moment. Production breaks, an alert fires, and the first ten minutes go to remembering, not fixing. "Did we see this before?" "Which runbook handles this?" "Who fixed it last time, and how?"

Existing tools like PagerDuty, Sentry, and Jira are great at storing tickets. None of them store knowledge. Every incident gets solved once, written up once, then forgotten, only to be solved again from scratch months later by someone else on the team. Chronicle was built to close that gap.

What it does

Chronicle is an AI native incident command center with a persistent operational memory layer wrapped around the entire incident lifecycle. The system gets smarter with every incident it processes.

The core loop:

Alert fires, gets deduplicated by fingerprint, auto triaged by AI, and posted to Slack. The AI pulls from memory (Mem0 and pgvector) to surface what happened last time. An SLA daemon watches the clock in the background. Once resolved, the learnings get written back to memory and a postmortem drafts itself.

Platform features:

  • Persistent AI memory: a dual layer vector store (Mem0 and pgvector) permanently embeds every resolution
  • Multi source ingestion: normalizes alerts from Sentry, UptimeRobot, GitHub, Slack, our own host agent, and manual reports into one incident model
  • Custom RAG pipeline: Groq's llama-3.3-70b-versatile runs parallel retrieval across Mem0, pgvector, and runbooks before ever generating a response
  • Alert deduplication: SHA based fingerprinting merges duplicate signals from multiple sources within a 10 minute window
  • SLA auto escalation: a background daemon escalates P3 to P2 to P1 to P0 automatically, checking every 60 seconds, with both time based and scope based escalation rules
  • Runbook retrieval: semantic vector search matches live incidents to the right step by step playbook, with a "safe to automate" mode and confidence threshold controls
  • Response analytics: 30 day MTTR trend charts, a 7x24 hour incident heatmap, and severity breakdowns
  • Auto postmortems: AI drafts a full structured postmortem (summary, timeline, root cause, impact, resolution, lessons learned) the moment an incident resolves, with a draft to review to published workflow
  • On call routing: roster management with Slack identity, weekly rotation grid, and automatic assignment on escalation
  • Host agent: a lightweight Node.js daemon with baseline learning, anomaly detection, circuit breaker logic, and graceful shutdown handling
  • Multi org auth: Clerk powered authentication with full data isolation at every layer

AI capabilities specifically:

The agent can search memory across all three sources, score incident severity using keyword and criticality weighting, suggest fixes ranked by confidence, escalate to the right on call engineer, generate postmortems, send Slack notifications, enforce status transitions, write new memories, check SLA status in real time, and verify a fix worked with a live health check.

ShopFlow, the live chaos demo:

We built ShopFlow, a real e-commerce storefront with a working cart, checkout, and payment flow, specifically so incidents in Chronicle aren't seeded fake data. It has a Chaos Control Panel with 8 triggerable failure scenarios, including payment timeouts, duplicate transactions, Stripe webhook failures, gateway overload, checkout crashes, slow search, Redis memory pressure, and SSL certificate expiry. Trigger one and watch a real incident appear in Chronicle within seconds, complete with an SLA countdown.

How I built it

Chronicle is a monorepo built with pnpm workspaces and Turborepo, split into four services.

The dashboard runs on Next.js 14 with Tailwind CSS and Clerk gated routes, covering 8 pages: Command Center, Incidents, Incident Detail, Analytics, Runbooks, Postmortems, Agent Fleet, On Call, and Settings. The API is an Express and TypeScript backend handling ingestion, orchestration, SLA logic, and the full REST surface. ShopFlow is a standalone Next.js storefront built to generate real, triggerable incidents. The Chronicle Agent is a separate Node.js daemon that ships host telemetry into the pipeline.

The AI layer uses a parallel prefetch architecture. Before the LLM is ever called, Chronicle queries Mem0, pgvector, and the runbook index simultaneously, merges the results into one enriched system prompt, and sends a single call to Groq. No agentic tool call loops, no round trips. Total response time lands around 3 to 8 seconds.

Memory embeddings are generated with a self contained 1536 dimensional deterministic embedding function built from character frequency and word level hashing, so the system doesn't depend on an external embedding API.

Deduplication, SLA escalation, and postmortem generation all run as background daemons rather than request time logic, so the system keeps working even when nobody is looking at the dashboard.

Everything is deployed, not just demoed locally. The dashboard and ShopFlow run on Vercel, the API runs on Render, backed by Supabase PostgreSQL with pgvector, Upstash Redis for rate limiting, Resend for email, and Slack's Bolt SDK for notifications.

Challenges I ran into

Getting Mem0 and pgvector to return complementary context instead of redundant context took real iteration on the retrieval and ranking logic.

Making ShopFlow trigger genuinely new incidents in Chronicle within seconds, rather than faking a canned demo, meant wiring real webhook ingestion end to end with HMAC verification and fingerprint deduplication.

The SLA daemon needed careful state machine design to avoid race conditions between automatic escalation and manual status updates coming from the dashboard.

Running three separately deployed services with cross service auth and Render's free tier cold start behavior added real deployment complexity under time pressure.

Our demo video did not come together the way we wanted, due to editing software crashing and a slow venue connection right at the deadline. The gap between what we actually shipped and what we could show in five minutes of video is real, and the fully deployed, live system is the honest proof of what we built.

Accomplishments that I'm proud of

We shipped a fully deployed, three service production system during the hackathon window, not a local only prototype. We built a dual layer AI memory system that retrieves genuinely relevant past incidents instead of generic model guesses. We built ShopFlow as a real interactive chaos engineering demo so the product's core value can be experienced live, not just described. We got the full lifecycle working end to end automatically: ingest, deduplicate, triage, recall, resolve, learn, and postmortem, without manual intervention at any stage.

What I learned

We learned how to design a RAG system that queries multiple retrieval sources in parallel and reconciles them, rather than treating vector search as one black box. We learned the operational difference between request time AI features and daemon driven background intelligence, like SLA escalation and deduplication, and why real incident tooling needs both. We also learned how much deployment and infrastructure planning matters, even in a hackathon, if you want people to actually use what you built instead of just watching a video of it.

What's next for Chronicle

Smarter deduplication that moves from fingerprint matching to semantic matching, so alerts worded differently but describing the same issue still get merged. Native PagerDuty and Datadog integrations alongside the current Sentry, UptimeRobot, GitHub, and Slack sources. A runbook authoring assistant that drafts a first version of a runbook automatically from a resolved incident's postmortem. Team level memory analytics that surface which categories of incidents keep recurring, so teams can prioritize root cause fixes over repeat firefighting. And a self serve onboarding flow so any team can connect their alert sources and be live in minutes.

Built With

Share this project:

Updates