Fix Incidents with Trusty AI
Hand an incident to Trusty AI in one click to obtain a remediation plan: get the likely root cause and the steps to fix it, without re-describing the problem.
When a monitor triggers, Decube tells you what broke. Fix with Trusty AI takes the next step: it hands the full incident context to Trusty and asks for the likely root cause and the remediation steps, so you move from alert to fix without piecing the story together yourself.
Where to find it
The Fix with Trusty AI button sits in the top right of the header on the Incident Details page, to the left of View monitor.
The button is available on any incident regardless of status.
Before you begin
We highly recommend adding the Incident Remediation skill to your Trusty interface.
The skill gives Trusty a fixed procedure for working an incident: which context to pull and in what order, how to judge whether the data actually broke or the monitor is miscalibrated, and how to lay out the fix. Without it, Trusty still answers, but the depth and shape of the answer vary from incident to incident. With it, every incident gets the same structured investigation against the same quality bar.
For what skills are and how to use them on other surfaces, see Skills.
How does it work?
Select an incident to open the Incident Details page.
Click Fix with Trusty AI in the top right of the incident header.
Trusty opens in a new browser tab with the details pre-filled within the prompt box. You can add or remove any context that is not required.
Read the remediation plan, then continue the conversation in the same session to dig deeper.
What gets sent to Trusty
Each click starts a new Trusty session. It never posts into a session you already have open, so the incident is answered against a clean context and your existing conversations are left untouched.
The first message is composed for you and carries a structured summary of the incident:
Incident ID
The unique ID of the incident, so Trusty can look up the full record
Affected asset
The table, column, or data job the incident was raised against
Incident type
Freshness, Volume, Field Health, Schema Drift, Custom SQL, or Job Failure
Incident level
Info, Warning, or Critical
What triggered it
The name and description of the test that breached
Observed & expected values
The value recorded at detection and expected values
Trusty can then pull further detail on its own: the monitor's run history, incident history, lineage, and profiling.
What Trusty gives back
With the Incident Remediation skill in place, Trusty replies in plain language with a full remediation plan:
The diagnosis — whether the data actually broke or the monitor is miscalibrated, and the evidence behind that call.
The likely root cause — what most plausibly caused the breach, including whether this incident is a symptom of an upstream job failure or schema change.
The downstream impact — the dashboards, reports, and jobs consuming the affected data, so you know who to warn.
The next steps — ranked remediation actions with an owner against each, plus advisory SQL you can run yourself to localise the problem.
How it gets verified — what confirms the fix has landed before you close the incident.
The answer is shaped by the incident type. For example:
A Freshness incident points you at load schedules and upstream job timing
A Schema Drift incident points you at the structural change and the downstream consumers exposed to it.
You will not get the same generic advice for both.
Where Trusty cannot land on a root cause with reasonable confidence, it says so and tells you what to check next rather than presenting a guess as fact. Nevertheless, as with any Trusty response, verify anything critical.
Last updated