Monitoring Lakeflow Jobs Runs

What it is

Lakeflow Jobs keeps a record of every run: when it started, how long it took, which tasks succeeded and which failed. The UI turns that record into views that show trends over time and the state of one run.

Monitoring answers two questions. Is this run normal compared with earlier runs? And if it failed or ran long, which task caused it?

How it works

Run history for one job

Open the job from Jobs & Pipelines and select its Runs tab. It has two views.

In the matrix view, bar height shows relative run duration, so a run that took twice as long as usual stands out at once. Hovering a bar or task cell shows its start time, duration and state.

Task cell colors make failures easy to spot.

Comparing against a baseline

The baseline is simply the job's recent normal runs. Compare the current bar with the bars before it, and compare each task cell's duration to find which task grew.

A slow trend across many runs usually means growing data volume or a layout problem. A single long run more often points to one bad input or a busy cluster.

You can set an expected completion time on the job. A warning appears when a run exceeds it, and a duration warning notification can alert the team before a timeout ends the run.

For longer history and reporting, the system.lakeflow system tables hold job and task run records across the account. Query them to chart run times and failure rates beyond what the UI shows.

Runs across all jobs

The Runs tab of Jobs & Pipelines lists runs of every job and pipeline you can access. With the list filtered to jobs or to pipelines, it shows a finished runs count graph for the last 48 hours, split into successful, failed and skipped runs.

It also lists the top 5 error types in the selected range. Filters such as run status and error code help track failure rates across the whole workspace.

Run statuses

A leaf task has no downstream tasks. That is why a failed task with a successful downstream task can still produce Succeeded with failures, for example when the downstream task runs on a condition other than All succeeded.

The task graph and upstream blockers

Opening a run shows its tasks as a graph that follows the job's dependencies. Each task carries its status, so the first red task in the chain is the blocker.

With the default Run if setting of All succeeded, tasks below a failed task do not run and the run fails. Fix the first failure; the rest are only waiting on it.

Click the failed task to open its task run details, with the output and error message. For a Lakeflow Declarative Pipelines task, the pipeline's own page shows its dataset graph and event log with the failure.

Repairing a run

Repair run reruns only the unsuccessful tasks and the tasks that depend on them. Successful tasks are not rerun, which saves time and cost on long jobs.

Repair uses the current job settings, and you can override parameters in the repair dialog. Repair applies to jobs with two or more tasks; a single task job is simply run again.

How the exam asks about this

• "Find whether today's run is slower than usual." Use the job's Runs tab matrix view and compare the run duration bars.
• "A job failed and four downstream tasks did not run." Open the run's task graph and fix the first failed upstream task.
• "Rerun only what failed after fixing a bug in one notebook." Use Repair run.