Is there an upper limit to number of parallel executions of an automation?

I’m defining a long running automation that should do some work, wait for a week (delay), then do something more and finalize. I expect to have 14 instances of this automation running concurrently.

I was testing the automation by triggering it from a button. As part of the code, it increments a counter. I clicked until it reached 10, then it stopped incrementing. I looked in the traces of the automation, and while the traces are there, all nodes in the trace are white - not one step has seemingly been performed on the automation instances beyond the 10.

Is there an upper limit to how many concurrent instances that can run? If yes, can this upper limit be changed?

What? A WEEK?

Long waits are horrible for HA.
Id strongly advise you go back and figure out how to do it with triggers.

2 Likes

Haha, yeah, I know it’s not great but I actually hoped that the management of the tasks was optimized enough to let it lay dormant until the delay wakes up.

I guess I’ll have to find a different solution model… :blush:

Not not great there’s no way to survive a restart unless you handle it which you’d handle it with a trigger to reenter your wait.

Once you’ve done that you might as well make it trigger based (which is how it should be done in the first place)

As was already mentioned, long running automations are an anti-pattern that will just cause you problems. If you post more details I’m sure you can get some advice on a different way of modeling the automation and specifically its triggers.

To answer your question for posterity’s sake… the default limit for parallel execution instances is, in fact, 10. It’s configurable, though.

Don’t use delay, just make input_datetime helpers and schedule the task to run when the input_datetime helper time has been reached.

setting the datetime a week from now.

action: input_datetime.set_datetime
target:
  entity_id: input_datetime.abc
data:
  datetime: "{{ now() + timedelta(days=7) }}"

A datetime trigger

trigger: time
at: input_datetime.abc

example

alias: My automation that does something
triggers:
- id: schedule
  trigger: state
  entity_id: binary_sensor.motion
  to: 'on'
- id: run
  trigger: time
  at: input_datetime.abc
actions:
- if:
  - condition: trigger
    id: schedule
  then:
  - action: input_datetime.set_datetime
    target:
      entity_id: input_datetime.abc
    data:
      datetime: "{{ now() + timedelta(days=7) }}"
  else:
  # Do run here.
3 Likes

My limit for any automation is usually only 5 minutes. Maybe 10 or 15 for automations that aren’t important. And for critical automations I use a datetime trigger as the delay. A week is absolutely a no-go.

you might get away with it if you NEVER restart HA. But I wouldn’t even come close to using that by factors of 100.

1 Like

Ok, just to recap so that I am sure I understand the takeaways:

The automation can be triggered in two ways and based on that have two flows: (1) by some arbitrary trigger (sensor etc) and also (2) a time trigger. If the automation is triggered by the former, flow 1 runs and the datetime is set to some date the future on the input_datetime. The automation will then be triggered at that time and flow 2 will run.

The second takeaway is that during the time between flow 1 and 2 there’s no active instance of the automation. Better for resource management and avoids any issues of max limit on delayed automations … plus more durable.

Yeah, thanks for the heads up. I’m going to go down the trigger route as described here in the thread.

1 Like

Yep, that’s the idea

As finity mentioned above, long running tasks should be avoided

1 Like