A job or pipeline did not do its work: its last run on the Runs page says Failed or Skipped, or, for a job with Email when a run fails switched on, you got that email. Every run records why, in its own words.
Why it happens
A run ends in one of these states:
| Status | What happened |
|---|---|
| Failed | The run started and a step could not finish. The Error column says which and why. |
| Skipped | The platform deliberately did not start it. Not an error: the reason is in the run. |
| Cancelled | Someone pressed Stop, or a run was cancelled through the API or an assistant. |
The common causes of Failed: the SQL does not compile or fails against the warehouse, the person the job runs as lost access to a database, or the run went over its budget.
Fix it
1. Read the error
Open Runs, set the status filter to Failed (or Skipped), and open the run. The Error column shows the failed step's message, shortened; the opened run shows it in full, with each step, its status and message, and the Whole run log.
2. Match the message
"This pipeline does not compile", or a message starting with a file name and line. The SQL has a problem. Open the pipeline: its header says how many problems it has, and the Problems tab under the editor lists each with its file and line. Fix them until it says Compiles, then use Dry run to check against your warehouse without writing anything.
A message starting with a table name in quotes, such as "daily_sales": …. The SQL compiled, but the warehouse failed while building that table, for example a column that no longer exists in a source. Use Run file on that file to try it on a sample.
"… can no longer write to …" / "… can no longer query …" / "… can no longer run the pipeline …" / "Someone with access must open the job and save it." A job runs as the person who last saved it, and a pipeline inside a job as the pipeline's author. That person lost access to a database, or left the account. Someone who still has access opens the job (or pipeline) and saves it, which makes them the person it runs as. A pipeline whose author left says "This pipeline has no owner any more. Open it and save it to take it over."
"This run exceeded its time budget of N s.", "This run passed its time budget of N s and was asked to stop." or "This job ran out of its time budget …". Every run is held to a budget of time, rows, data and memory that comes from your warehouse tier. Make the run do less: put a WHERE in the source views so fewer rows travel, give big tables a KEY so a run only rewrites what changed, and avoid Full refresh unless you need it. Check that the job has not lowered its own budget. If you need more, a bigger warehouse tier raises it; see Jobs & Pipelines.
"The warehouse this pipeline writes into no longer exists." The warehouse database the pipeline builds into was deleted, so the pipeline has nowhere to write.
"The steps of this job wait for each other in a loop …". Open the job and remove one of the links the message names.
"We could not reach the server holding your warehouse. Nothing was run." A platform problem, not your SQL. Run it again later; if it repeats, contact us.
3. Skipped runs
The run's message says why:
- "Previous run still running." The job was due again while its last run was going, and it is set to Skip the new run. Set If a run is still going when the next is due to Queue it, or schedule it less often.
- "Too many runs already waiting for this account." The queue of waiting runs is full. Spread your schedules out.
- "Not run: this month's spend cap is reached." The Runs page also says so at the top. Scheduled runs are skipped and Run now is refused "until the month turns or you raise the cap". Raise the Monthly spend cap under Settings → Billing; see Usage, the spend cap and the forecast. Dashboards and queries keep working.
4. Run it again
Once fixed, press Run now on the job, or Run pipeline on the pipeline. A run that is stuck or was started by mistake can be ended with Stop.
Runs that failed for platform reasons are never counted against your job minutes.
Still stuck?
Copy the Whole run log of the failed run. Your AI assistant can read the same run with get_job_run, and check a pipeline's SQL with compile_pipeline without running anything. If the log points at the platform rather than your SQL, contact us with the run's link.