Platform 2 min read

Diagnose with AI: failed runs that explain themselves

When a run fails, one click reads what it actually logged, classifies the failure, and explains it in plain language. The evidence is redacted on the server before it reaches your browser or any model — and proposed fixes are shown as a diff you review and save yourself.

A failed run tells you it failed. Finding out why has always meant reading logs written for whoever wrote the code, not for whoever has to fix it at 8am.

Diagnose with AI turns that into a button. It's available on pipeline runs, artifacts, and automation runs.

The classification happens before any AI does

Before a model is involved at all, a deterministic classifier labels what went wrong: an empty configuration, an empty window, schema drift, a malformed URL, an authentication failure, a quota problem, or something transient.

That matters for two reasons. Failures that have a definite answer get the definite answer, and the explanation you read afterwards is anchored to a real classification instead of a model's impression of one.

Your credentials never reach the model

This is the part we care most about, and it works the way it should rather than the way that's easy.

Evidence is redacted on the server, before it is sent to your browser or to any model. Not filtered in the UI. Not trusted to a prompt.

Raw response-body dumps and Spark row dumps are dropped entirely — not masked, dropped — because a body dump is the single most likely place for your actual customer data to be sitting in a log. On top of that, URL query strings, bearer tokens, database connection credentials, SQL literals in WHERE clauses, email addresses, and long digit sequences are all redacted before the payload leaves the server.

Container logs are a separate, opt-in step. Nothing pulls them automatically.

An AI feature that reads your logs is ordinary now. One that does the redaction on the server — before the payload leaves it, rather than trusting a prompt to behave — is the version worth shipping.

Proposed fixes, never applied fixes

For request-configuration problems — a wrong route, base URL, method, parameter, or header — Databasin can go further and propose the correction. It arrives as a field-by-field diff: here's what you have, here's what it should be, here's why.

You review it and you save it. In the product's own words: nothing is changed automatically.

And a proposal is only badged Verified when the corrected request actually reached the vendor and came back healthy. If it couldn't be proven, it says so, and tells you what wasn't verified. A confident-sounding wrong answer is worse than no answer, so an unproven fix has to look unproven.

What it won't pretend to fix

Auto-Fix handles request configuration. Credential problems, transient failures, and schema drift are diagnosed and explained, then explicitly handed back with what needs to happen instead — rather than a fix that looks plausible and isn't.

The goal isn't a product that claims to repair itself. It's the end of reading a stack trace to find out that somebody renamed a column.

NewerDatabasin One goes with you: hand your chat to your phone → News & insights ← Point at a database, get a pipeline: ingestion that works itself outOlder

See it on your own data — five minutes, $50 in credit, no card.