I guess it depends on usecase.

If the instance is stopped at -5 minutes and another job comes in at -4, there will be a short delay on that next job while the instance is restarted, but it won't really cost any more than it would have done if the instance had been left running.

But if I have a job finish at -2 and then keep the instance running 5 minutes in case another job comes, then I have to pay a whole extra hour for no reason.

Generally for us, if a build fails and there's nothing in the queue it's at least a few minutes, often longer, before we've found the failure and pushed the fix. So the behaviour as-is works fairly well for us.

Perhaps actually what's needed is a configurable idle time (after last job completion) and a "Wait till the end of an instance-hour to stop instances" checkbox. Stopping an instance takes a fairly consistent amount of time, and I don't think there's a usecase where you'd intentionally want to stop it with say half an hour left? So the minutes left cutoff could just be hardcoded - say 2 minutes before the hour, to be safe.

Then the logic would be something like:

if (time_since_last_build_finished > idle_time) {
  if (wait_till_end_of_instance_hour && (minutes_of_instance_hour_left > 2)) {
    return;
  }
  stopInstance();
}

We'd probably just configure it with the wait checkbox ticked and an idle time of 0, but users with more regular builds could configure a longer idle time at risk of sometimes pushing the instance into an extra hour.

Interesting point - stopping the instance then starting it almost immediately actually doesn't matter that much unless your instances do lots of expensive work on startup.

I suspect it's much more of a problem if you're using instance store root and terminating your instances, where bringup could take quite a while. Then again most people doing that are probably using custom AMIs that're as pre-configured as possible already.

Perhaps it's not worth doing anything about.

I've put together a patch that'll document it and will leave it at that for now. I think I'll switch to negative timeouts and see how it goes on my deployment.

This pull request incorporates the documentation change:

https://github.com/jenkinsci/ec2-plugin/pull/101