# Scheduling SSIS Integration Runtime

> An SSIS integration runtime bills for its nodes every hour it runs, and the schedule stops and starts exactly that. Package data in SSISDB survives untouched. Starting the runtime is the slow half, routinely 5-20 minutes of provisioning, so the morning cron must lead the first Execute SSIS Package activity comfortably.

Source: https://zop.dev/integrations/azure/ssis-ir/schedule
Updated: 2026-08-19

---

## The runtime is the cost, the packages are safe

An SSIS IR is a fleet of VMs Data Factory keeps warm to run packages, and those node-hours are
the entire charge worth attacking. The packages themselves live in SSISDB, hosted on an Azure
SQL resource that persists and bills independently. Stopping the IR risks no package, no
project and no history: it parks the compute and nothing else.

## Provisioning makes the start the hard deadline

Stopping is quick; starting is not. Bringing an SSIS IR up means provisioning its nodes from
scratch, routinely 5-20 minutes and occasionally longer. Every scheduled morning must absorb
that lag: an IR that starts at 6:00 for pipelines that fire at 6:05 will spend the first weeks
failing. Lead the earliest package execution by half an hour and the problem never exists.

## Pipelines fail cleanly while it is down

An Execute SSIS Package activity against a stopped IR fails with a clear error rather than
hanging, which is friendly for diagnosis and unfriendly for unattended pipelines. The robust pattern
pairs the schedule with the pipeline calendar: nightly ETL finishes, the IR stops behind it,
and nothing is triggered into the gap. Ad-hoc daytime runs are unaffected because the IR is up
exactly when humans are.

## SSISDB bills on its own meter

The catalog database keeps its own Azure SQL pricing regardless of the IR's state. On serverless
Azure SQL it may pause on its own once the IR stops touching it, compounding the saving; on
provisioned tiers it will not. Either way, quote the schedule's saving in IR node-hours, not
as the whole Data Factory line.

## The arithmetic favors big nodes

SSIS IRs often run large VM sizes for licensing and throughput reasons, and a handful of
Enterprise-sized nodes idle from 7pm to 7am is real money. Twelve hours a night times node
count times an Enterprise-tier rate is the number to put in the business case.