Handoff

Watches on-call incident threads, drafts the handoff, pings the next responder, escalates if they don't ack.

Comment

Inspiration

On-call handoffs are broken. When a responder's shift ends, the next person inherits an incident thread with dozens of messages, edits, and side conversations but no structured summary. We watched teammates spend the first 15–30 minutes of their shift just catching up, often repeating steps that had already been tried. We built HANDOFF so that context transfers automatically, reliably, and in real time.

What it does

HANDOFF is a Slack agent that watches an incident thread, maintains a live running summary, and generates a structured handoff card on demand.

  • Real-time thread watching — every new message triggers a fresh pull of the thread and an updated summary.
  • /handoff — drafts a handoff card (what happened, actions taken, open items, key links), looks up the incoming on-call from HANDOFF's built-in schedule, and posts the card with an Acknowledge button.
  • Acknowledgment tracking — the incoming responder clicks Acknowledge; the card updates in place.
  • Escalation — a pg_cron sweep finds unacknowledged handoffs past the timeout and posts a notice tagging the team lead.
  • /handoff status — lists active incidents and their acknowledgment state across the workspace.
  • MCP server — the same get_on_call and escalate tools are exposed as OAuth-protected MCP tools, so any AI client can drive the same primitives. ## How we built it
  • Frontend / API: TanStack Start on Vite, deployed on Lovable Cloud / Cloudflare Workers.
  • Backend / Auth / Storage: Lovable Cloud (Supabase) with Row-Level Security, Postgres, and pg_cron.
  • AI: Lovable AI Gateway (Gemini) with a structured-output summarizer.
  • Slack integration: Signature-verified events, slash commands, and interactive buttons via public API routes.
  • MCP: @lovable.dev/mcp-js OAuth-protected MCP server exposing on-call and escalation tools.
  • State model: incidents, ack_tokens, on_call_schedule, and escalation_contacts tables. ## Challenges we ran into
  • Slack slash commands do not include a thread_ts, so we had to resolve the incident thread from the message text, permalink, or the latest active incident in the channel.
  • Background event processing had to be synchronized so Slack requests did not terminate before bot replies were sent.
  • We originally planned to integrate PagerDuty directly, but switched to a built-in schedule to keep the demo self-contained and avoid requiring every judge to have a PagerDuty account. ## Accomplishments that we're proud of
  • A genuinely load-bearing MCP server: the same tools power both the Slack bot and any external AI client.
  • Real-time summarization that re-reads the full thread on every message, so edits and deletions are reflected automatically.
  • A working end-to-end demo flow: mention HANDOFF in a thread, run /handoff, click Acknowledge, and watch escalation fire if missed. ## What we learned
  • Slack's event and command payloads differ subtly in shape and timing; robust normalization and verbose logging are essential.
  • Building the on-call schedule ourselves made the demo far more reliable than depending on an external service.
  • Structured LLM outputs are the difference between a fragile regex parser and a trustworthy handoff card. ## What's next for Handoff
  • Bi-directional PagerDuty/Opsgenie integration for teams that already have an on-call vendor.
  • Persistent incident timeline export and post-mortem generation.
  • Smart routing based on incident severity and responder skills.
  • A web dashboard for schedule management and incident history.

Built With

  • cloudflare-workers
  • google-gemini
  • lovable-ai
  • lovable-cloud
  • mcp
  • pg-cron
  • postgresql
  • react
  • slack-api
  • slack-block-kit
  • supabase
  • tailwindcss
  • tanstack-start
  • typescript
Share this project:

Updates

Submission history