And an idea that eventually became BlastTrace.
It All Started with a Late-Night Conversation...
Not every project begins with a hackathon problem statement or a college assignment.
Sometimes, it begins with two friends discussing something completely random late at night.
For us, it was a conversation about the Barclays banking outage in the UK.
We had heard about the disruption through a relative who had experienced it, and one night, Chinmay and I started discussing what had happened.
Thousands of customers had faced difficulties accessing banking services and making payments during the January 2025 outage.
But what caught our attention wasn't just the disruption. It was a question that kept bothering us.
How can one software failure affect so many people? And why can identifying its root cause be so complicated?
We weren't banking experts or DevOps engineers. We were just two first-year students trying to understand how something like this could happen.
And then, almost jokingly, a thought popped up.
"Wait... what if we could build something that helps engineers investigate failures like this?"
There was a pause.
"Can we actually do that?"
We had absolutely no idea.
But we decided to find out.
And that's where the first thought behind BlastTrace was born.
One Week of Research, Endless Questions
For the next week, our curiosity turned into research.
We explored monitoring systems, root-cause analysis platforms, AI-based debugging tools, incident reports, and how development teams manage software changes.
And slowly, we noticed something interesting.
Datadog could tell engineers when something was going wrong.
GitHub could show what code had changed.
Jira could explain why a particular change was made.
APM tools could reveal which part of an application was failing.
Deployment records could tell when a change reached production.
All the information was there.
But the connections between those pieces weren't always easy to find.
An engineer might have to jump between multiple platforms, compare timestamps, inspect commits, and manually reconstruct what happened.
Different tools. Different clues. One incident.
We kept coming back to the same question:
What if a system could connect all this information and investigate it together?
We finally had the beginning of an idea.
But there was still something missing.
But Wait... How Do Things Actually Work Inside Companies?
Reading about production incidents is one thing. Understanding how engineers actually handle them inside companies is another.
We were students. Neither of us had experienced a real production outage as part of an engineering team.
So we reached out to relatives working in the tech industry.
We asked how developers manage changes, how Jira and GitHub fit into actual workflows, what happens during deployments, and how teams investigate production incidents.
Those conversations were genuinely eye-opening.
We realized that a software failure isn't always about a single error message. It can involve multiple connected services, recent code changes, dependencies, deployments, and historical incidents.
We went back to our initial design and refined the architecture.
Instead of building an AI tool that simply reads logs and suggests possible fixes, we wanted something that could trace a software change from its original requirement all the way to a production incident.
And then came another challenge.
A slightly more personal one.
“Yaar, Hum Ye Build Kar Paayenge Kya?”
Let's be real.
And here we were planning something involving AI, graph databases, GitHub, Jira, monitoring systems, code analysis, webhooks, and automated root-cause investigation.
Even saying all of that sounded intimidating.
I remember thinking:
"Yaar, hum ye build kar paayenge kya? First year mein humse hoga?"
Because having an ambitious idea and actually building it are two very different things.
We could have chosen something much simpler.
But that's where having the right teammate makes all the difference.
Chinmay's response was simple:
"Hoga yaar. Let's just try. We'll figure it out."
And somehow, that was enough.
We didn't know every technology we'd need.
We didn't know how many errors were waiting for us.
But we decided to start anyway.
The Missing Piece: Not More Data, but Connected Data
As we began designing BlastTrace, one realization changed our entire approach.
The problem wasn't that engineers lacked information. It was that the information lacked connections.
We needed something different.
Enter FalkorDB
This is where FalkorDB became the heart of BlastTrace.
Using FalkorDB, we could represent the software development lifecycle as a connected knowledge graph.
A Jira ticket wasn't just an isolated task anymore. It could be connected to pull requests, Git commits, modified code components, services, deployments, and incidents.
When a service failed, BlastTrace could use multi-hop Cypher graph traversals to narrow the investigation to relevant changes.
We combined this with ChromaDB for semantic code matching and Groq-powered AI for analysis.
Instead of asking an AI to guess what went wrong from an error message, our goal was to give it connected evidence to reason over.
That's how the architecture of BlastTrace-Falkor started taking shape.
Inside BlastTrace: Two Engines, One Connected System
We designed BlastTrace around two interconnected engines.
Engine A — The Software Factory works proactively, helping developers understand the potential impact of changes before deployment.
Engine B — The Observability Engine works reactively, investigating incidents after something goes wrong.
Both share the same knowledge graph, allowing development history to become context for incident investigations.
Our architecture follows a 21-step workflow, connecting requirements, code changes, deployments, alerts, and historical feedback.
Engine A: The Software Factory — Before Things Break
Requirement Ingestion: A new requirement or bug report enters through Jira or our dashboard's Generate Jira trigger.
Knowledge Graph Creation: Our FastAPI backend receives the Jira webhook and creates a
Ticketnode in FalkorDB.Predictive Dependency Analysis: ChromaDB identifies semantically relevant code components while FalkorDB traces their dependencies and potentially affected services.
Live Rulebook Fetching: BlastTrace fetches
.blasttrace_rules.md, a project-specific rulebook we created and pushed to GitHub.AI Test Plan Generation: Groq uses the rulebook and dependency context to generate a Test & Blast-Radius Blueprint identifying affected services, APIs, and required tests.
Verification Loop: The generated blueprint is checked against the project's coding guidelines, service boundaries, and testing requirements.
Jira Integration: The verified blueprint can be posted back to the Jira ticket through the Jira REST API.
Git-to-Jira Linking: As development progresses, commits, pull requests, and their associated Jira requirements are connected in FalkorDB.
Code Verification: Pull-request diffs are evaluated against the generated blueprint to identify potentially missing tests or requirements.
Graph–Vector Fusion: Source-code components are indexed in ChromaDB and linked to their corresponding FalkorDB graph nodes.
Deployment Tracking: Deployment relationships connect released commits to the services they affect, preserving the context needed for future investigations.
The goal? Help developers identify possible risks before they become production incidents.
Engine B: The Observability Engine — After Something Breaks
Log Ingestion: BlastTrace receives monitoring alerts and error logs through adapters such as Datadog's webhook integration.
APM Trace Ingestion: Detailed execution traces provide additional context about failing functions and components. For our demonstration, we use simulated AppDynamics-style APM telemetry.
Anomaly Correlation: Log symptoms and execution-trace context are brought together to help identify the affected component or service.
Unified Alert Creation: FastAPI normalizes the incident information and creates a connected
Alertnode in FalkorDB.Multi-Hop Graph Traversal: Cypher queries trace relationships from the affected service through relevant components, deployments, and Git commits, narrowing the investigation.
Hybrid Graph + Vector Search: BlastTrace compares the graph-connected suspects using semantic code-diff similarity, structural relationships, temporal relevance, and past incident context.
Top-3 RCA Ranking: The system ranks three probable root causes, providing confidence scores and technical evidence linked to code changes.
Interactive Investigation Dashboard: The findings appear in our Investigate interface, including probable commits, supporting diffs, and associated Jira context.
Graph Weight Calibration: Engineer feedback can strengthen or adjust relationships between validated root causes and affected components.
Persistent Institutional Memory: Post-mortem information is stored in ChromaDB and linked with FalkorDB, making validated incident context available for future investigations.
The Bug That Stole an Entire Day
Of course, explaining a 21-step architecture is much easier than actually making all 21 steps work together.
And one particular day still makes us laugh.
BlastTrace just wasn't giving us the output we expected.
We checked everything.
The database. The graph connections. The retrieval logic. The indexing pipeline.
Nothing made sense.
Hours passed, and our frustration kept growing.
Was the problem with FalkorDB? Was our code indexing wrong? Was the AI missing context?
After almost an entire day of debugging, we finally discovered the unexpected culprit.
*Me. Sneha. *
I had accidentally been wiping the very codebase data that BlastTrace was supposed to analyze!
We'd spent hours questioning our architecture when the evidence our system needed wasn't even staying there.
The next day, we couldn't stop laughing about it.
The irony was perfect.
We were building a root-cause analysis system while struggling to find the root cause of our own bug!
That experience taught us something important.
Before expecting AI to reason intelligently, make sure the underlying data and connections are actually there.
And sometimes, the problem isn't where you're looking.
We Broke Salesforce E-Bikes — On Purpose
Once BlastTrace started working, we needed a meaningful way to test it.
We didn't want a demo where an AI simply displayed a predefined answer.
We wanted actual source-code changes, real Git commits, and repeatable incident scenarios.
So we forked Salesforce's open-source E-Bikes Lightning Web Components application.
And then we deliberately introduced two bugs.
Both changes were committed to GitHub.
We used these controlled scenarios to test whether BlastTrace could connect an incident to relevant components, changes, and development history.
We also integrated real Datadog webhook support.
For easier evaluation, we added one-click incident triggers to the dashboard, allowing the same backend investigation pipeline to be tested without manually setting up a Datadog alert every time.
And because our chosen APM provider required organizational registration, we created a simulator to provide representative APM traces.
The incident scenarios were controlled. The Git history was real. The project rulebook was fetched live from GitHub. And the RCA investigation used our actual graph and semantic analysis pipeline.
Watching BlastTrace finally connect these pieces together was one of the most satisfying parts of the project.
The idea we had discussed late at night was slowly becoming something real.
From Confusion to Clarity — Even the Name Started Making Sense
Somewhere between the failed executions, endless discussions, and debugging sessions, things began falling into place.
The architecture made sense.
The two engines were connected.
And now we needed a name.
Something that actually represented what our system was trying to do.
A software failure can feel like a blast—one problem spreading across connected systems.
And our goal was to trace that blast back through the evidence to understand where it might have originated.
Blast + Trace = BlastTrace.
Even our logo followed the same idea: a burst with lines radiating outward, representing how an incident can spread across connected components.
And then came one of our favorite parts.
The UI/UX.
We didn't want BlastTrace to look like another dashboard filled with endless logs, tables, and technical data.
We wanted the interface to represent the idea of connected systems.
That's how our rotating, building-like digital visualization became part of the homepage.
We remember sitting back in our chairs, watching that structure rotate on the screen.
And for a moment, we just looked at it.
What had started with rough sketches, confusing discussions, and endless debugging had turned into an actual application—with its own name, logo, interface, and identity.
What Building BlastTrace Taught Us
Looking back, this journey wasn't just about learning Python, FastAPI, FalkorDB, or AI.
It taught us how different technologies come together to solve a larger problem.
We learned that connecting APIs is only the beginning. Making their data meaningful together is the real challenge.
We learned why graph databases matter when the answer depends on relationships rather than isolated pieces of information.
And we learned that debugging requires patience, especially when you're debugging a system designed to debug other systems.
Most importantly, we learned how much difference the right teammate makes.
When one person gets stuck, the other brings a new perspective.
Is BlastTrace perfect?
Not yet.
There are more integrations we want to improve, more real-world scenarios we want to test, and many things we still want to learn.
But that's not what we're most proud of.
We're proud that we started something we genuinely weren't sure we could build.
Explore BlastTrace
GitHub Repository: https://github.com/Chinmay1516-ops/BlastTrace-Falkor.git
Working Demo Video: https://youtu.be/jcgvUy7pPas?si=V2kmy5vhlOVVY5uV
Built by Chinmay Pingale & Sneha Kumari .
Top comments (0)