Scheduling SSIS Integration Runtime
Can ZopNight schedule 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.
How the stop works
| Field | Value |
|---|---|
| Behaviour | stopped and started via the integration-runtime stop/start operations, halting node billing while stopped. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
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.