Databricks Job Failure Agent with OpenCode
The whole job is a chain of reads followed by exactly one write into Linear, with a Slack line reserved for the jobs your runbook notes flag. It is bounded, repetitive and defined by a document you wrote. OpenCode is easy to aim at a loop like that, and being model agnostic means the history classification can be tuned without touching a word of the runbook.
Watch it work before it's live
Run a staged conversation — no account needed. The agent handles it for real while a simulated world answers its tool calls; nothing touches real accounts, and nothing is actually sent.
nightly_revenue_rollup
Run 4471028 failed at 02:14 UTC after 6 minutes on task build_revenue_facts. Error: org.apache.spark.sql.AnalysisException: [UNRESOLVED_COLUMN.WITH_SUGGESTION] A column with name `order_total_usd` cannot be resolved. Did you mean one of: [order_total, currency_code]? Line 42, pos 8.
Set up in minutes
Using this template drops you into a guided setup. It asks exactly this, nothing else:
Connect Databricks
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Linear
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Slack
One sign-in. The agent acts through your account, scoped to what this template uses.
Runbook notes
What each job is for and what breaks when it does not run - which jobs are business critical, the tables and dashboards fed by them, who owns each one, and the jobs that are allowed to fail quietly overnight.
Runs on OpenCode
Preselected for this page — connect your OpenCode account during setup, or switch to NoClick's built-in models with one click.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
Why OpenCode for this agent
One write, everything else read
Runs, run output and job definitions are all reads. The single write is a Linear issue, filed only when the search came back with no open match.
Runbook notes carry the context
Which jobs are critical, what feeds off them and who owns each one are yours to describe. The harness supplies reasoning, not opinions about your platform.
Before you fork
Can it retry the failed run if it looks transient?
No, and that is on purpose. Retrying, cancelling, editing a job or its schedule, and restarting or resizing a cluster are all outside its reach. An executor loss that looks retryable is sometimes a cluster that should not come back, and a retry loop on a job writing to a warehouse is an expensive way to discover that. Automatic retries belong in a separate workflow you decide on deliberately.
Run it with a different agent
Put Databricks Job Failure Agent to work on OpenCode
Free to start. Guided setup, a test run against staged conversations, and it's live.