FailWhisperer

Inspiration

Every developer knows the 2 AM moment: a build or deployment breaks, and the answer is buried in a CI dashboard and hundreds of lines of raw logs. Voice assistants can tell you the weather, but not why your pipeline failed. FailWhisperer brings the assistant to the pipeline.

What it does

FailWhisperer is a DevOps voice companion. You ask out loud: "Did my last build break?", "Which runs failed this week?", "Pull the logs from that failure", "What actually broke, and how do I fix it?", "Investigate that failure in depth", and it answers in plain spoken English. An Amazon Bedrock model (Nova Lite) understands each question and routes it to the right one of five MCP tools; Bedrock also turns raw failure logs into an evidence-based explanation of what broke. It is an Alexa+-style experience delivered through a self-hosted web voice client and MCP server; it is not an official Alexa integration (live Alexa+ voice is partner-gated), and the client is generic: it can connect to any MCP server by URL.

How I built it

A Spring Boot (Spring AI MCP) server over Streamable HTTP implementing MCP spec 2025-11-25+, with five read-only tools: get_build_status, get_failed_runs, get_failure_logs, summarize_failure (Bedrock-powered), and investigate_failure (deep investigation combining longer log excerpts with up to three changed files pinned to the run's head SHA). A separate Spring Boot AI routing API uses Bedrock Nova Lite to select the approved tool for each question. The frontend is a React + TypeScript voice client using the official MCP TypeScript client, with speech in and out and a Connect handshake that discovers the server's tools. Backend deployed on Railway, frontend on Vercel. The AI cannot deploy, rerun builds, or modify repositories: it is read-only by design, and summaries distinguish observations from uncertainty.

Challenges / friction log

1. Railway platform incident, Oct 22: the whole deployment path went dark mid-week. Builds and deploys stalled; as part of Railway's mitigation they revoked all API tokens and invalidated OAuth sessions, then notified upstream providers to proactively revoke exposed keys. Effect on the build: the deployment pipeline behind the demo could not be trusted on shoot night. Workaround: added a 15-minute pre-flight before recording: railway login from scratch, re-verify the GitHub auto-deploy integration in the dashboard (a "redeploy" against a broken link silently does nothing), and treat the two keys the demo depends on as compromised: the GitHub PAT behind the failed-runs/logs tools, and the AWS key behind summarize_failure. Kept a local-server fallback so recording was never hostage to the deployment platform.

2. The climax question's key may already have been dead. Railway told upstream providers to proactively revoke keys from affected accounts, so the AWS key behind summarize_failure, the Bedrock-powered climax of the demo chain, was assumed revoked even before rotation was confirmed. So the pre-shoot pre-flight treated both keys as compromised and planned rotation before recording, rather than testing-and-discovering mid-take.

3. Loom can't hear the demo. The FailWhisperer voice plays inside the browser tab, and the Loom Chrome extension does not capture tab audio in Full Screen or Window modes, so the app's spoken answers never landed in the take. Evaluated iOS screen recording as a fallback, then pivoted to the CapCut Desktop screen recorder (system audio + microphone in one panel): the app's answers and my spoken questions record together, and the clip drops straight into the edit timeline: one app for record, edit, captions, and voice enhancement. One setting that would have silently broken everything: CapCut needs Mac Screen Recording and Microphone permissions first.

4. Speech recognition isn't a studio. Browser speech recognition can mishear mid-take. Rule for the shoot: never stop recording on a mishear: pause, repeat the question cleanly, fix it in the edit. The answers still come back spoken, which is what the demo needs.

Honest limitation: live Alexa+ voice is partner-gated, so the demo runs through the self-hosted web voice client. The Echo appears only as the vision beat, never as a working device.

Per-tool feedback

• get_build_status: the fast path. One spoken question replaces a CI dashboard check. Worked exactly as specified.
• get_failed_runs: GitHub-backed. The one that exposed the key-revocation risk, since a dead PAT fails silently behind a friendly voice.
• get_failure_logs: raw log on screen is the point. Showing the mess before the explanation is what sells the summary.
• summarize_failure: the Bedrock moment. Long log in, plain-language cause + fix out. The AWS key behind this one needed rotation after the Railway incident.
• investigate_failure: the closer. Deeper investigation from longer log excerpts with changed files pinned to the run's head SHA. Stronger ending than the summary alone.

Accomplishments that I'm proud of

A complete voice loop: question spoken, Bedrock routes it, a real MCP tool executes against live GitHub Actions data, and the answer is spoken back. Plus surviving a major Railway platform/security incident mid-hackathon week without losing the submission.

What I learned

MCP's tool-discovery handshake makes a generic voice client possible; routing natural language to a fixed, approved tool set with an LLM is safer and more predictable than free-form agent actions; and platform incidents are part of shipping: designing a local fallback kept the demo alive.

What's next for FailWhisperer

Deeper multi-job and PR-aware investigations, more CI providers beyond GitHub Actions, and a live Alexa+ integration when partner access opens.

Built With

• amazon-bedrock
• amazon-nova-lite
• aws-sdk
• github-actions
• github-api
• java
• javascript
• mcp
• mcp-typescript-sdk
• model-context-protocol
• railway
• react
• spring
• spring-ai
• spring-boot
• tailwind-css
• typescript
• vercel
• vite
• web-speech-api