Inspiration
We came to a simple observation: incident management tools know who's on-call, but none of them know who's actually in the zone. Research shows it takes 23 minutes to re-enter deep focus after an interruption, and on-call engineers burn out at 2.5x more deep focus than their peers. We wanted to build something that treated engineers as humans with cognitive states, not names on a rotation. So we built fl0w for the Neuroscience & Mental Health track.
What it does
Fl0w detects if an each engineer real-time cognitive state is in deep work, available, recovering or offline by reading GitHub activity, Slack presence, burnout scores from Rootly and Jira tickets. When an incident fires, it checks if the engineer on call is in deep work or in burnout and if other engineers are available. If it is the case, it will change the shift to the available engineers and page them for the incident. A live dashboard shows the team's state, and a weekly generated report (with Claude) gives engineering leads a plain-language summary of flow patterns and burnout risk across the team to help them identify patterns and make clearer decisions.
How we built it
The backend is a FastAPI server in Python that polls the GitHub Events API and Slack Web API to classify each engineer's state every few seconds. Incident routing decisions are made via the Rootly webhook. With it we are able to read created incident and deleted incident. Weekly reports are generated with the Claude API (claude-sonnet-4-6), which synthesizes each engineer's flow history into a readable narrative. State history is persisted in Supabase (Postgres). The frontend is built in React with Recharts for the 24-hour activity timeline visualization.
Challenges we ran into
Gathering reliable real-time signals was tougher than expected. GitHub required specific permissions to access commits across the repo. Navigating Rootly’s big documentation was the biggest hurdle, though their chatbot helped. Deployment was also a challenge; since our product is containerized, every image must pass multiple checks, and a single failure breaks the entire pipeline.
Accomplishments that we're proud of
We’re proud to have pulled off this project on such a tight schedule with a concept we find genuinely interesting. We also built a functional end-to-end workflow that interacts with users and managed to complete the deployment within the deadline.
What we learned
While building fl0w, we learned how to integrate multiple real-time APIs (Github, Slack, Rootly) to manage the developer's cognitive states without manual intervention. We also learned how to automate Jira ticket complexity analysis.
What's next for Fl0w
Live Feed: A dashboard sidebar that tracks real-time status changes, allowing leads to monitor engineer flow states in detail.
Calendar API Integration: Automatically blocks meetings during peak flow windows to protect deep work.
Built With
- api
- docker
- fastapi
- python
- react
- supabase
- tailwind
- typescript
- vite
Log in or sign up for Devpost to join the conversation.