# Azure ML Job

> Azure ML jobs are transient training, pipeline, or scoring runs that bill through the compute they occupy, not as standing resources. ZopNight records each job's status and target-compute linkage via the AML enricher, feeding utilization evidence into ML compute recommendations that separate busy clusters from idle allocations.

Source: https://zop.dev/integrations/azure/ml-job
Updated: 2026-08-19

---

ML jobs are individual training, pipeline, or scoring runs executed on ML compute. Jobs reveal which clusters are actually earning their keep and which are idle allocations.

## A run, not a resource: how job cost accrues

A job has no meter of its own. Its cost is the node-hours it occupies on the compute it targets: a compute cluster's VMs while the run executes, released when it finishes. That indirection is why job spend never appears as a "job" line anywhere: it lands on the cluster. The corollary is that a runaway job is a compute leak wearing a workload's name, billing cluster nodes for as long as it stays in a running state.

## The evidence trail ZopNight builds from jobs

Discovered via the AML enricher with status and target-compute linkage. Each job's record ties an execution to the cluster that hosted it, feeding utilization evidence into ML compute recommendations. A cluster whose job history is empty for weeks while it holds a warm minimum is exactly the pattern this linkage exposes, since the jobs are the proof that allocated capacity is or is not being used.

## Why jobs are discovery-only

Jobs are transient executions rather than standing infrastructure, so there is nothing for a schedule to stop and restart: pausing a half-finished training run is not a savings action, it is a broken experiment. ZopNight therefore treats jobs as read-only telemetry, and applies its scheduling to the clusters and instances the jobs run on.

## Job-shaped waste to watch for

The patterns worth hunting: runs stuck in a running state long after their expected duration, holding nodes; retry loops resubmitting a failing pipeline against an expensive cluster; and experiment sweeps launched at a parallelism the team never reviewed. Each shows up first in the job list, not the cost report.

## Reading the run history in ML studio

Azure ML studio → Jobs lists runs with status, duration, and target compute; sort by duration to find the runs that held nodes longest.
