I was thinking of a waitfor, but that would make the run time information harder to use. I want to know how long the backup takes, for example. If it runs 20 minutes rather than 10 minutes, I will want investigate. However, perhaps the metric is the actual end time of the last backup - one metric for all servers. I could also create a report that gets the backup times directly instead.

In the long run, I was hoping the master job script can include a list of average runtimes. (With a job that collects this data and updates the job being deployed.) I suppose I could collect the second step time from each instance and create a wait that depends on the sum from instances "scheduled" before it (e.g., those prior in the list).

I also can't have it completely random because of other non-maintenance jobs. However, I do like the idea. It would be an easy way to handle some of the servers on the SAN.