Skip to main content

AI Diagnostics

When something goes wrong with a pipeline, you have two ways to figure out why: dig into the job run logs directly, or let Melty AI read the failure and explain it in plain language.

There are also two ways to get that plain-language read from Melty AI:

  1. 'Diagnose' button - click the 'Diagnose' button on any failed pipeline run in the Pipelines view to generate a diagnosis on demand.
  2. Failure alert emails - whenever a pipeline run fails and you get a failure alert by email, the diagnosis is already included, along with one-click actions matched to that failure.

Both surface the same underlying diagnosis, generated the same way, so it doesn't matter which one you read first.


Diagnosing pipeline runs and logs

Every pipeline in your workspace can be inspected directly from the Pipelines view, without needing Melty AI. Each pipeline card lists its recent job runs, and expanding any run shows the full logs for that execution.

View a pipeline's job runs

  1. Open the Pipelines view from the left navigation bar.
  2. Find the pipeline you want to inspect. Each pipeline is shown as a card with its name and latest run status.
  3. Click the chevron () on the pipeline card to expand it and reveal its recent job runs.

View logs for a specific run

  1. With the pipeline card expanded, locate the pipeline run you want to inspect.
  2. Click on that run to open its logs.
  3. Use the logs to see exactly what happened during that run - useful for spotting errors, warnings, or unexpected behaviour before reaching for a deeper diagnosis.

If a run failed and you want more than raw logs - for example, a plain language explanation of what went wrong and how to fix it - see Diagnosing pipelines with Melty AI below.

Before you start

Melty AI runs on your own Claude API key, so there's a one-time setup step before you can use either the Diagnose button or diagnosis-in-email.

  1. Go to Settings > Advanced Settings > Claude
  2. Add your Claude API key
  3. If you don't have one yet, generate one from the Anthropic Console

You only need to do this once. Once a key is added, Diagnose is available on any failing pipeline, and your failure alert emails start including a diagnosis automatically.

If no key is configured, failure alert emails still send, just without a diagnosis. Instead, the email explains plainly what a diagnosis would contain and exactly what data it would send, with a link to the privacy disclosure, so turning it on is an informed decision rather than something that happens by default.

Diagnosing pipelines with Melty AI

When a pipeline fails, Melty AI reads the failure and explains what went wrong in plain language, along with suggested steps to fix it. You can get that diagnosis two ways: by clicking Diagnose in the app, or automatically in the failure alert email.

Method 1: The Diagnose button

1. Find a failing pipeline

Open the Pipelines view. Any pipeline whose latest run has failed shows a 'Diagnose' button next to it.

2. Click 'Diagnose'

If this is your first time using the feature, you'll see an introduction explaining what Melty AI does and what data it uses, with a prompt to add your Claude API key if you haven't already. Once a key is on file, clicking 'Diagnose' goes straight to generating a diagnosis.

3. Read the diagnosis

Melty AI gathers the failure logs, recent run history, pipeline code, and pipeline configuration, and sends that context to Claude. The result appears in a popup with:

  • A short title summarizing the failure
  • A plain language explanation of what went wrong
  • Suggested steps to resolve it

4. Close the popup

Click Close when you're done. Your diagnosis isn't lost - it's saved against that run, so you can come back to it later without generating it again.

Method 2: Diagnose-and-act email alerts

When a pipeline fails, the email alone usually can't tell you what to do next. It says a run failed, but to find out why, someone has to stop what they're doing, log in, find the run, open the logs, read the stack trace, and form a theory, before they can even start on a fix. On a busy team that gap is measured in hours, and in the meantime your data is stale and it isn't always clear whose job it is to jump on it.

Diagnose-and-act alerts close that gap. Every failure email carries a plain-language diagnosis of what went wrong, plus a row of one-click actions matched to that specific failure, so you (or anyone you forward the email to) can act immediately, without opening Meltano first.

What's in the alert

A failure alert has two parts: a diagnosis, and a set of actions built from it.

Pipeline "daily_salesforce_sync" failed
run #482 · exit 1 · 07:14 UTC

What to do next
The target rejected the load because the api_token setting is
missing after a recent config change. Restore the token in the
pipeline's settings, or edit the source file that references it,
then re-run.

[ Edit config file ] [ Check pipeline settings ]
[ Send to support ] [ Stop this pipeline ]

The diagnosis is a short, plain-language explanation of what went wrong and what to do about it, written directly into the email. The actions underneath it aren't a fixed set of boilerplate links: they're chosen to match the specific failure, so the person reading the email can respond right away.

Available actions

ActionWhat it does
Edit config fileAppears when the diagnosis points to a specific configuration file. Links straight to that file so you can fix it without hunting for it.
Check pipeline settingsOpens the pipeline's settings in Meltano, for failures traced to a setting rather than a file.
Send to supportOpens a pre-filled note to support, so escalating a failure you can't resolve yourself doesn't mean writing up the context from scratch.
Stop this pipelinePauses the pipeline in one click, so a failing job stops burning runs on its schedule while someone investigates.

The stop action is scoped to the one pipeline named in the alert, and clicking it still requires you to log in. It can't be used to pause or disable anything you aren't already permitted to.

Only a genuine, final failure is diagnosed, not every retry along the way. Diagnosing an email failure uses its own path through the system: it doesn't ride on, or affect the reliability of, the Diagnose button it borrows its intelligence from. A slow, failed, or unconfigured diagnosis never costs you the underlying failure alert, that part always sends.

Diagnosis caching

Once a diagnosis is generated for a failed run - whether from the Diagnose button or from a failure email - it's cached in your workspace and shared between both surfaces. Reopening that failure, or opening the pipeline in Meltano after reading the email, shows the cached diagnosis instead of generating a new one, so you're not spending API tokens asking the same question twice.

A new diagnosis is only generated when:

  • You're viewing a failure for the first time, or
  • The pipeline fails again on a subsequent run

Only the diagnosis itself is cached, not the raw logs, code, or context that was sent to Claude to produce it.

Data handling and privacy

Because Melty AI sends pipeline logs and code to Claude to generate a diagnosis, this section explains exactly what's sent, what's protected, and where it goes. This applies the same way whether the diagnosis was triggered by the Diagnose button or generated for a failure alert email.

What Melty AI looks at

Four things, and only these four:

  • Failure logs for the run that triggered the diagnosis
  • Recent run history for that pipeline, so Claude can tell whether this is a new failure or a recurring one
  • Pipeline code, the configuration hosted in your pipeline's git repository
  • Pipeline metadata, such as which plugins and triggers are configured

Melty AI does not look at data from other pipelines, other workspaces, or anything outside what's needed to diagnose the specific failure you clicked into.

What's removed before anything is sent

Before any of the above leaves Meltano, it passes through an automatic redaction step. This uses URL and key-pattern scrubbing, combined with Meltano's secret-setting flags, to strip out:

  • Credentials, tokens, and API keys that may appear in logs or configuration
  • Connection strings and secrets referenced in pipeline code
  • Any other values Meltano's redaction system is configured to treat as sensitive

This happens automatically and applies the same way everywhere a pipeline's logs are surfaced. There's no setting to turn it off. For failure alert emails specifically, this same redaction also strips any embedded credentials from every link in the email itself.

What Meltano stores, and what it doesn't

Meltano stores the generated diagnosis in your workspace, so reopening a failure doesn't require regenerating it or spending tokens again. Meltano also records token usage for accounting purposes.

Meltano does not persist the raw context, logs, code, or configuration that was sent to Claude to produce a diagnosis. That data exists only for the duration of the request.

Where the request goes

Melty AI runs on your own Claude API key, so each request is made under your own Anthropic account rather than a shared Meltano-owned key. The redacted context is sent directly to Claude via Anthropic's API. Because the request is made under your account, Anthropic's handling of that data is governed by Anthropic's privacy and data usage policies, not Meltano's.

Your control over this

  • The Diagnose button only runs when you click it. It never runs automatically on a failure.
  • Diagnosis-in-email only runs if you've added a Claude API key; otherwise the failure alert still sends, just without a diagnosis.
  • If you haven't added a Claude API key, no data is sent anywhere - you'll be prompted to add one first when using the Diagnose button.
  • You can remove your Claude API key at any time from Settings > Advanced Settings > Claude, which disables both the Diagnose button and diagnosis-in-email until a new key is added.

Questions

If you have questions about this feature or want to report something that looks wrong in a diagnosis, contact Meltano support or reach out through your usual support channel.