← All work
2026
2nd of 45+ teams
AI
Dashboard
DevOps
Night Shift
A live incident dashboard for an AI on-call agent that runs on one Dell Pro Max with GB10.
Role
Mission Control design owner, pitch deck and demo video
Timeline
Oct 25, 2026 (one-day hackathon)
Tools
Claude Code, Claude, uPlot, Slack
Status
2nd of 45+ teams
Watch the demo ↗

Overview
Night Shift is an AI on-call agent our team of three built in one day at the Dell × NVIDIA AI Hackathon in San Francisco. It watches Acme, a fictional demo store with synthetic data, works out what broke, proposes a fix in Slack, and runs it only after a person clicks Allow once. Every model call runs on one Dell Pro Max with GB10.
I owned Mission Control, the live dashboard the judges watched during the demo. I also made the pitch deck and the demo video.
Challenge
When production breaks at 3 a.m., the engineer on call has to work out what changed, why, and what to undo, half awake. PagerDuty’s 2024 survey puts the average incident at 175 minutes (self-reported).
AI could shorten that, but many teams that handle sensitive data aren’t allowed to paste production logs into a cloud model. Night Shift keeps every model call on one box.
That created a design problem of its own. The agent works in the background, and the fix waits for a person in Slack. Judges, and later on-call engineers, needed one screen that shows what the agent sees, what it thinks and what it is waiting for, readable from across a room. It could never look more confident than it really was.
Constraints
One day, built in parallel. The engine, the agent and the dashboard were built at the same time. I designed against the agreed data contract and a labelled sample replay, before the backend existed.
A projector, not a laptop. The screen runs at 1920×1080 on a big display: body text at least 18 px, key numbers at least 28 px.
Nothing loaded from the internet. Plain HTML, CSS and JavaScript with one bundled charting library (uPlot), no frameworks or CDNs.
Honesty rules. Label synthetic history and estimated money, say “Local AI inference” rather than claiming zero cloud bytes, and never show sample data as live.
Process
Start from the story, not the panels. The demo has one arc: a bad deploy ships, the error line climbs, and Night Shift warns, diagnoses, asks, fixes and proves the fix. I laid the screen out in that order. A live chart of checkout errors runs across the top, with dashed markers for the deploy, early warning, alert, approval and recovery. Services sit on the right. Below them come the four specialist cards with their combined diagnosis, then the timeline. A row of tiles along the bottom carries time to detect, time to diagnosis, time to recovery and the local inference count.
Design every state, not just the happy one. Idle, incident open, investigating, diagnosis ready, fixing, resolved. Then the states nobody wants to show on stage: the engine unreachable (panels dim under a banner), a specialist falling back to rules (FALLBACK badge), a mock model in development (MOCK badge), and sample mode (an amber “SAMPLE DATA, not live” banner).
Build against a contract. I wrote the layout and the rules, then built the dashboard with Claude Code against the engine’s API and event stream. Until the real engine was ready, I worked from a sample replay of the bad-deploy scenario.
Make the controls stage-proof. Keys 1 to 5 inject the five failure scenarios and R resets, so the presenter never hunts for a button in front of judges.
Tell it twice. After the dashboard, I made the 7-slide pitch deck and a 1:55 demo video: a 30-second animated opener on the problem, then the two live runs with step labels, callouts on the key numbers and a voiceover.
Decisions & Tradeoffs
Show the fallback, even on stage. In the recorded bad-deploy run, all four specialist cards came back as FALLBACK. The dashboard said so in amber instead of dressing it up as a model result. That made a less flattering demo, but one a judge or an engineer can trust.
“Local AI inference”, not “0 cloud bytes”. Slack is still a cloud service, so a zero-bytes claim would not hold up. The label says what we can prove: every model call runs on the box.
Label every number that isn’t measured. The 46.7-minute average comes from Acme’s synthetic history, and dollars protected is an estimate. Both say so on screen.
One chart with markers, not more charts. Deploy, warning, alert, approval and recovery all sit on the same error line, so the whole incident reads left to right at a glance. The cost: labels crowd when events land seconds apart, and in the live run some of them overlap.
Result
Both live runs worked end to end on the GB10, and Mission Control showed each step as it happened.
Bad deploy. Early warning at 11 s, diagnosis at 42 s, resolved and verified at 212 s (3 min 32 s). That includes the wait for a person to approve and a full minute of healthy traffic. Acme’s synthetic history averages 46.7 minutes.
Prompt injection. The attacker’s “ignore all previous instructions” text showed up on the Slack card as untrusted data, with a proposal to block the client. After a person approved, the block was applied and verified, and the incident resolved 2 min 36 s after it began.
Sandbox. A test request from the sandbox to an outside server was blocked and logged by OpenShell.
We submitted the working prototype, the pitch deck and the demo video. The team placed second out of more than 45 teams.
What I’d Do Next
Test the dashboard with working on-call engineers, not only judges, and check whether they can say what is happening within 10 seconds.
Clean up the idle state: hide services with no traffic, hide the $0 tile until it has a value, and shorten the model name.
Give markers that land seconds apart stacked labels, so the chart stays readable.
Design a phone view, since the approval happens in Slack at 3 a.m., not at a desk.
How I used AI. I used Claude Code to build Mission Control from my layout and the team’s UI spec. I used Claude to cut the demo video, generate its voiceover and lay out the pitch deck. My teammates built the engine and the agent. What the dashboard shows, and how the story is told, are my decisions.
Next project →
