What Broke, Not Just That It Broke
Take a real example: a Zendesk pipeline fails with an ERROR status. Melty doesn’t stop at “it failed.” It names the exact stream and the exact cause: the extractor tap-zendesk failed syncing the automations stream because the Zendesk API rejected the request. The access token is expired, revoked, or malformed.
It flags this as a credential issue, not a config problem, and tells you what to do: update the Zendesk token and re-run the pipeline. That’s the difference between “something broke” and knowing your next move before you’ve opened the platform.
Set Up Once, Diagnosed Every Time
The diagnosis runs on your own Claude API key. Add it once, about a minute, from the link in your first failure email, and every failure after that comes with a full breakdown. Nothing else about your access changes. You still log in to make actual fixes.
To generate the diagnosis, Melty sends failure logs, run history, pipeline configuration, and any recent code changes. Each email links to a full disclosure of what’s shared. Retries don’t cost you anything either: only a genuine final failure triggers a diagnosis, and the result is cached and shared with the in-app view.
No key yet, or the AI step hiccups? You still get the plain alert. Diagnosis is best-effort, never a dependency, and it runs on its own path, separate from Melty AI’s in-product features.
Three Ways to Respond
Every diagnosis comes with the means to act on it:
- Fix it. A link under “What to do next” takes you straight to the setting, in the Zendesk case, the tap-zendesk connector.
- Stop it. A third link halts the job, including its schedule, with configuration kept intact for whenever you’re ready to restart.
Every link drops you on the exact pipeline in question. Nothing to search for.
Forward It, Safely
Forward the email as-is.Anyone with admin access who picks it up can log in with their own account and act directly, with no need to re-explain the failure. Before any of this reaches an email, built-in checks strip out credentials and secrets, so forwarding is safe by default, no matter how many people receive it.
Why It Matters
Most of the time lost to a pipeline failure isn’t spent fixing it. It’s spent figuring out what’s wrong. Every hour that gap stays open is an hour of stale dashboards and decisions made on old numbers.
Email is somewhere people already check, all day. Put the diagnosis there and the slowest part of any outage, working out what broke, collapses into opening your inbox.
Next time a pipeline fails: read the diagnosis, use the fix-it, support, or stop-job link, or forward it to an Admin who can. See it on your next failure, or try Meltano if you’re not running one yet.