Data Factory instances with zero successful pipeline runs, found but not billed as savings
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-261 |
| Category | idle |
| Severity | low |
| Metric | none — pure configuration read |
| Source | datafactory_idle.go |
Where it applies
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
az monitor metrics list \ --resource "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DataFactory/factories/<name>" \ --metric PipelineSucceededRuns \ --interval P1D --offset 30d --aggregation TotalThirty 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.