# Azure Data Factory Idle Pipeline > ZopNight detects Data Factory instances whose PipelineSucceededRuns metric averaged 0 over 30 days, but deliberately reports no dollar figure for them: Data Factory bills per activity run, so an idle factory already costs about $0 and deleting it recovers nothing measurable. Guided trigger-pause is the offered action. Source: https://zop.dev/integrations/azure/recommendations/azure-data-factory-idle-pipeline Updated: 2026-08-19 --- ## Usage-priced services break the idle-savings formula Most idle findings equate to money: the resource bills hourly, so silence equals waste. Azure Data Factory does not work that way. A factory is billed per pipeline-activity run, per integration-runtime hour actually consumed. There is no standing compute fee for the factory object itself. A factory with zero runs is already costing approximately nothing, so a delete recommendation claiming its rack-rate as savings would be a fabricated number. ZopNight's rule therefore detects the condition but abstains from emitting a costed recommendation. Honest zero beats invented dollars. ## What the detection actually reads The signal is the `PipelineSucceededRuns` Azure Monitor series over a 30-day window, and the factory must be in a succeeded provisioning state. An average of 0 successful runs marks the factory quiet. The rule reads only this named series, because Data Factory emits eleven metrics, and sampling an arbitrary one (failed runs, integration-runtime memory) could mislabel an active factory as idle. ## Inspect run history directly ```bash az monitor metrics list \ --resource "/subscriptions//resourceGroups//providers/Microsoft.DataFactory/factories/" \ --metric PipelineSucceededRuns \ --interval P1D --offset 30d --aggregation Total ``` Thirty zero days confirms nothing has run. ## The lever that exists is a pause, not a delete Data Factory appears in ZopNight's auto-remediation allowlist as a guided pause: turn off the pipeline triggers so scheduled runs stop, while every pipeline definition stays intact. That is the reversible action for a factory you suspect is abandoned. Deletion remains a manual call, because pipeline definitions embed connection and transformation logic that is tedious to reconstruct. ## Why you may still want to act Cost is not the only reason to retire a dead factory. Its linked services hold credentials and connection strings to data stores; an unmaintained factory is attack surface and audit noise. If the last successful run is months old, export the ARM template, disable triggers first, and delete after a quiet period. ## Signals that keep the rule quiet A factory in a failed or deleting provisioning state, an absent metric series, or any successful run in the window all end evaluation early. Reader and Monitoring Reader cover everything the detection reads.