Time constraints on an RTOS are what you need them to be for the domain.

On the RTOS I was the lead for, some constraints were measured in 100s of ns.

Edit to address the edit: our upper bound in that case was single digit microseconds.

My point was that once you pass the 100ms mark most would not consider it "real-time".

Ah it reads backwards, that you're asserting no one actually deals with constraints tighter than 100 ms.

We're coming from different directions. My upper bound was "after this point it won't be rtos", but I've reworded it entirely to be more clear.

Upper bound is a specific term in real time also unfortunately.

Might I suggest wording such as "upper bound constraints exceeding 100ms aren't typically addressed with real time methods".

For what I see from the discution it seems to be more a practical decision to not use real time resources and techniques for much higher times. So 1 day for example would be a waste of development time to try to use real time, you could use alerts and background jobs to fix issues. But when you reach shorter and shorter timeframes and bad things can happen a real time approach starts to make more sense.

Now, some parent comment mentioned RTOS. Maybe for a real time OS there would be a practical hard upper bound. But for real time systems in general this upper bound would be totally domain specific.