The short answer: one condition can span midnight
A time condition checks the clock at the moment it runs and stops the automation when the check does not pass, so it is a gate rather than an alarm. According to the official Time condition reference, the window goes past midnight whenever before is earlier than after. That is exactly what after: "22:00:00" and before: "06:00:00" describe, and the same page uses that pair for its own hallway-light example, where the window runs from 22:00 until 06:00 the next morning:
conditions:
- condition: time
after: "22:00:00"
before: "06:00:00"There is no need to split that into two OR branches. Conditions are combined with AND by default, and one condition sitting on its own is already a complete gate, as the conditions overview explains. A split or only combines condition truth values, so it can help when two independently expressed windows should count as one gate; it is not required to cross midnight. Different behavior in each half belongs to a separate choose or if action after the gate, not to the or. You need at least one of after, before, or weekday; both keys together are what make the wrap work.
Where the window starts and stops
after is inclusive and before is exclusive: the window starts exactly at the after time and ends just before the before time. The reference page gives a clean example: with after: "15:00:00" and before: "02:00:00", the condition passes at 15:00:00 but not at 02:00:00. A lone after runs until midnight; a lone before starts from midnight.
Clock time |
|
|---|---|
21:59 | false |
22:00 | true |
00:00 | true |
05:59 | true |
06:00 | false |
Passing at 22:00 is not the same as starting at 22:00: the condition only gates a run that a trigger already started, so a time trigger — or another trigger — still has to fire at that moment for the automation to run. A time-condition evaluation at 06:00 fails for this window. That does not automatically cancel an action sequence already running: a condition checks when evaluated, rather than continuously supervising or stopping a run.
Weekdays follow the current calendar day
weekday checks the current day, and the hours after midnight already belong to the next day. At 01:00 on a Saturday, the condition passes for sat, not fri, even though the window opened on Friday night. Here is a hypothetical window; the weekday list is illustrative, not a recommendation for a particular schedule:
conditions:
- condition: time
after: "22:00:00"
before: "06:00:00"
weekday:
- fri
- satWith that list, Friday 23:00 passes because it is Friday, Saturday 01:00 passes because it is Saturday, and Sunday 01:00 fails because Sunday is not selected. The label in your head, such as "Friday night" or "the weekend", is not what Home Assistant evaluates, so write the weekday list for the day on which the run actually happens.
Time zone, helpers, and what this condition is not
The check uses the time zone configured in Home Assistant under Settings > System > Home information, so the same YAML can behave differently after that setting changes, or on a system whose clock and zone do not match your local time. When after or before points at a date and time helper, only the helper's time counts and the date part is ignored. A helper that is unknown or unavailable does not pass the condition, which is easy to miss when the helper is normally set from a routine that itself skipped a night.
Finally, a condition only gates a run that a trigger already started: to start an automation at 23:30 you need a time trigger, and the condition then filters that run.
If it still stops at night, check these four things
Work through this checklist; each item produces the same symptom, an automation that quietly does nothing:
- The edges. Confirm which side of 22:00 and 06:00 the run lands on, using the table above.
- The weekday list. After midnight, the day that counts is the new one, not the evening the window began.
- The time zone. Compare it with the clock you assumed when you wrote the schedule.
- The helper. If a helper supplies a bound, check its current state;
unknownandunavailablefail the condition. Also confirm the trigger fired at all, since no condition can wake an automation by itself.
A safe way to test and trace it
Prove the gate with a temporary test automation: give it a real trigger — a test time, or a button you press — and a harmless notification action, add the time condition, then check that the notification arrives while the window is satisfied and is skipped while it is not. Don't treat the manual Run actions button as proof that the time condition passes; it may skip triggers and top-level conditions, so it can start an action list the real gate would have blocked. If your Home Assistant version offers a condition test or trace view, prefer it. Never test the window by firing heating, locks, or other risky actions, and restore your real settings once the test is over.
A run trace is the most reliable evidence afterwards: it shows whether the condition passed and where a run ended, which is the fastest way to tell a wrong boundary from a wrong trigger. Connected Home Notes's guide to delays and automation traces walks through reading one. We have not run Home Assistant on your system, so treat these steps as documentation-based checks, not a report of a live test.
Two neighbouring topics stay outside this article on purpose. Connected Home Notes's separate guide to trigger IDs for branching one automation covers routing several triggers through choose, and the delay guide covers what happens when a run waits inside an action.



