Quiet Time limitations (especially for repeating journeys)

Quiet time is a delivery control, not a journey-entry control. Contacts can still progress through the journey, but if a message lands inside a quiet-time window, it’s held (queued) and then released when quiet time ends. In one-time journeys with a static audience, you can often reduce the risk (or size) of a post–quiet time burst by controlling when the audience is allowed to start—for example, by scheduling the start and/or using entry controls like rate limiting. In repeating daily journeys, however, that kind of start-time control isn’t really available—so messages can pile up over the weekend and then flush in a burst on Monday when quiet time ends. And because the backlog is held in the platform’s internal queue during quiet time, it isn’t something you can access as regular records to dedupe or throttle manually before sending resumes.

Why this is hard to fix today

This is the part most people don’t realize until it happens in production: once messages are already queued by quiet time, there isn’t a supported way to dedupe or smoothly throttle that queued backlog before it releases (at least none that I’ve found so far).

• Adding waits/time windows after the send step doesn’t help—because the send is what gets queued.
• Journey rate limiting doesn’t solve the flush either—quiet time can still create a burst when the window ends and it is only available for One -Time Journey with static audience.
• Frequency capping helps prevent message fatigue across journeys, but it doesn’t address the “quiet time backlog flush” behavior—and it can affect other programs depending on how your caps and exclusions are configured.

Status: I’m still actively looking into a viable, repeatable solution pattern for this (that doesn’t introduce new tradeoffs). If I find one that works consistently, I’ll publish a follow-up with the exact design.