Pipeline incident investigation
Something broke in your pipeline. Find out why.
Your monitoring already noticed. Decim does the part that comes next: it finds the pipeline and the step, reads the logs, weighs every explanation and confirms the cause with evidence you can check. Then it proposes the fix and writes the report.
The product, start to finish
From something broke to a confirmed cause
Connect · Discover · Investigate · Explain
A diagnosis, in the shape it arrives
EUR rows, a normal night
≈ 41,000
EUR rows since Tuesday
0
Transaction volume
−38%
Confidence
92%
Root cause
A change on Tuesday made the staging step's currency filter default to USD and GBP, so every EUR row was excluded from the nightly load.
Commit 9f3c2e1 replaced the list ('USD','GBP','EUR') with a parameter, @Currencies, defaulting to 'USD,GBP'. The scheduled job calls the procedure without it, and the step still reports success with zero errors. The upstream export still carries about 41,000 EUR rows a night, so the rows were lost in staging, not at the source.
Ruled out · 18%
A late FX rates file: it landed before conversion ran, and every currency pair had a rate.
Ruled out · 9%
The core banking export stopped sending EUR: it still carries about 41,000 EUR rows a night.
Sample data from the product's demo workspace, the same incident as the film. In the product every reference above opens the artefact behind it: the log lines as they were read, the healthy run they were compared with, the commit and its diff, the check your team ran and what it returned.
Monitoring tells you it broke. It cannot tell you why.
Detection is a solved problem and you almost certainly have it. What it does not do is walk backwards through the pipeline, find the step where the data went wrong, join that to the change that caused it and prove it.
Failure mode 01
Success with missing rows
The job exits zero, the scheduler goes green, and part of the data never arrived. A filter, a mapping or a default parameter quietly excluded it, and nothing in the run status separates this from a clean load, because the code did exactly what it was written to do.
Failure mode 02
One cause, six symptoms
A late file, a slow stage or a changed upstream export shows up as a dashboard that is wrong, a report that is late and a row count that is down. The alerts fire downstream, where the damage is visible, not at the step where it started.
Failure mode 03
The cause is in a commit
The pipeline did not break on its own: someone changed it. A release reworked a query, a parameter got a new default, a mapping lost a value. The evidence is spread across logs, code history and a ticket, and nobody has joined them up yet.
The hour after the alert
When a pipeline breaks quietly, the investigation that follows is almost always the same. Someone opens the run history and compares tonight's numbers with last week's. They find which pipeline writes the table that looks wrong, then which step inside it. They read that step's logs, and the logs of the steps either side, looking for the place where the numbers stop adding up. They check what was deployed recently, read the diff, form a theory, and go and look for the one fact that would prove it.
An experienced engineer does this well. They also do it at two in the morning, from memory, while the people downstream ask for an answer. The reasoning ends up in a chat thread, the theories that were ruled out are lost, and the next time the same symptom appears the work starts again from zero.
What Decim does with that hour
Decim runs the same procedure, in the same order, and writes all of it down. It already knows your pipelines because it has read the code. It reads the logs of each step itself and compares them with healthy runs. It keeps several explanations alive at once instead of committing to the first plausible one, and it says which evidence supports each and which contradicts it. When it needs a fact it cannot reach, it asks for exactly that fact, in the form of a query your team can run.
The result is not an answer in a chat window. It is a record: what was checked, what was found, what was ruled out and why, and what to change. That record is what makes the conclusion trustworthy, and it is what the next engineer, the auditor and the person writing the incident review will want.
From your code to a confirmed cause
Something else detected the problem: an alert, a failed job, a ticket from finance. Decim starts there, with the code it has already read and the logs it can reach.
01
Connect
Install the GitHub App and pick the repositories that hold your pipelines. Connect Google Cloud Logging with read-only access and name the log sources that matter. Connect Jira so incidents can start from a ticket. Where logs live on your own Windows servers, an optional agent reads files and Event Logs.
02
Discover
Decim reads the code and finds the pipelines in it, each defined by what starts it: a schedule, a queue, a file arriving, a batch command. For every pipeline it maps the steps from source to destination, with the lines of code behind each one, so an investigation knows where to look.
03
Investigate
Describe what is wrong in a sentence, or link the ticket. Decim locates the pipeline and the step, reads their logs one step at a time, compares them with healthy runs, weighs competing explanations and confirms the one the evidence supports. You can follow every step as it happens.
04
Fix
For a confirmed cause, Decim proposes the fix: a code patch, checked to apply cleanly, and a SQL repair for the data that was damaged, with the query to verify it. One click opens a draft pull request. Nothing is merged or run without a person deciding to.
05
Report
Every investigation exports as a board-ready PDF: what happened, why it happened, what was ruled out, the evidence behind each statement, how the cause was verified and what is being done about it. It is written for the people who were not in the incident channel.
Inside an investigation, phase by phase
Each phase appears on the incident's timeline as it happens. The quotes are from the worked example above.
01
Locate
Ranks your discovered pipelines and their steps against the description and the ticket, and cites the code that made the match.
“Nightly ledger load, 91% sure: the only pipeline writing fact_transactions. Starting at stg_transactions.”
02
Read the logs
Walks the steps, most suspicious first, and pulls their logs from Cloud Logging or the agent. Each step ends looked fine, found something, or an honest gap such as no logs.
“stg_transactions: EUR rows stop arriving on Tuesday. Extract ledger: looked fine, the export still has 40,887 EUR rows.”
03
Compare with healthy runs
Pulls the same step from successful runs up to 30 days back, so a finding is a difference from normal rather than a guess about what normal is.
“Every night before Tuesday the step logs a EUR line with about 41,000 rows.”
04
Weigh explanations
Proposes up to five competing causes, each with a confidence and the evidence for and against it, then runs an independent critique pass before anything is concluded.
“A Tuesday change excluded EUR: 61%. A late FX file: 48%. The upstream export stopped sending EUR: 35%.”
05
Settle it
Tests each explanation against everything it has collected. When the deciding fact lives where Decim cannot read, such as a database, it writes a read-only check for your team to run and folds the result back in.
“Row counts by currency before and after Tuesday: EUR goes to zero while USD and GBP hold steady.”
06
Conclude
Confirms a cause only when independent evidence corroborates it, never on confidence alone. Otherwise it says likely, unclear, or that it needs access to more logs.
“Confirmed, 92%: commit 9f3c2e1 changed the currency filter's default. Late FX file: rejected, 18%.”
There are four ways an investigation can end: cause found, likely cause when the evidence points one way without proving it, cause unclear when it does not settle the question, and needs log access when the step that matters writes no useful logs. You can challenge a conclusion or add a file at any point, and the investigation revises itself. More on the investigations page.
A diagnosis you cannot check is a guess
Every finding in a Decim investigation links to what it rests on: the log lines it read, the healthy run it compared them with, the lines of code involved, the commit that changed them, the ticket, the files you attached and the results of the checks your team ran. Nothing is paraphrased; the excerpt you see is the excerpt that was read.
Rejected explanations are kept too, each with the evidence that ruled it out. What an investigation rules out is often worth as much as what it rules in, because that is the search the next engineer would otherwise repeat.
Where the evidence does not support a conclusion, Decim reports the gap instead of filling it. An investigation that ends with the logs for this step do not show what happened is a useful result: it tells you where to add logging before the next incident.
The same record answers the question that arrives days later in a meeting: not just what broke but how do we know that is what broke. The PDF report carries the same citations, so the answer survives outside the product.
Cited evidence · ledger-nightly / step 3
2026-10-13 02:14:09 usp_load_transactions Loaded 57911 rows for USD
2026-10-13 02:14:09 usp_load_transactions Loaded 12206 rows for GBP
2026-10-13 02:14:10 usp_load_transactions Step completed successfully (0 errors)Healthy baseline · the night before
2026-10-12 02:13:52 usp_load_transactions Loaded 40903 rows for EURWhat every citation records
- Source The log source, file or ticket it came from, and the step it belongs to
- Location Byte offsets in the file, or the record ID in an event log
- Excerpt The exact lines, as they were read, never paraphrased
- Hash A fingerprint of what was read, so the excerpt can be checked against the source
- Time When the logged event happened, and when Decim read it
Your code, your logs, your tickets
Four connections are available today. Each is read-only, and each is chosen by you: Decim reads only the repositories, log sources and issues you point it at.
GitHub
Repositories you select: code, commits and pull requests as evidence. Pipeline discovery reads them, and fixes open as draft pull requests.
Google Cloud Logging
Read-only access through Google sign-in. You name the log sources, as filters, and investigations read entries from them.
Jira Cloud
Read-only. Start an incident from an issue; its description, comments and attachments are kept as evidence.
Windows agent
Optional, for logs that live on your own servers. Outbound only; it lists directories, reads files and reads Windows Event Logs.
Planned next: database connectors (SQL Server, PostgreSQL, MySQL, Oracle), schedulers and orchestrators (SQL Agent, Airflow, dbt, AWS Glue, Azure Data Factory), warehouses, other log stores such as Amazon CloudWatch, and alert intake from Datadog, PagerDuty and CloudWatch, which is in preview. See all integrations.
What makes it different
Investigation, not detection
Monitoring answers whether something is wrong, and you already have it. Decim starts from the alert, the ticket or the message in the channel, and works backwards through the pipeline to the step and the change that caused it.
Evidence, not a transcript
An investigation is a durable record: the steps examined, the log lines cited, the explanations weighed and the ones ruled out, with the evidence that ruled them out. The next person to see this failure inherits the work instead of repeating it.
Read-only by design
Decim reads code, logs and tickets with read-only access. It never runs a query against your systems; it writes the check for your team to run. It never merges; fixes arrive as draft pull requests you review like any other change.
You stay in control
Read-only access
GitHub, Cloud Logging and Jira are connected with read access to what you select. The optional agent only lists, reads files and reads event logs.
People make the changes
Checks are run by your team, fixes arrive as draft pull requests, and repairs are SQL you choose to run. Decim never merges or executes.
A record of everything
Every action in the workspace lands in an audit log you can export, and every conclusion keeps the evidence it was drawn from.
Common questions
Is Decim a monitoring tool?
How does Decim learn my pipelines?
Does Decim connect to my database?
What does Decim read, and where does it go?
Which stacks does it work with?
What do I get at the end of an investigation?
Will it ever change something on its own?
Get started
Bring us a pipeline that broke last week
The fastest way to evaluate this is a real incident you already know the answer to. If Decim gets it wrong, that is a far more useful demo than one where it doesn't.