Wait-until-conditions time-capped vs indefinite: proceed when met or when the timer expires

Indefinite wait-until holds the contact until the condition becomes true with no auto-expiry; a time-capped wait releases them when either the condition is met or the limit expires—whichever comes first.

What is the difference between time-capped and indefinite wait-until-conditions?

A wait-until-conditions step parks the profile until some profile/event state becomes true—paid invoice, finished lesson, entered a segment, property flipped. The design fork is whether that wait can sit forever or must expire.

Indefinite wait-until: no timer auto-releases them; they stay until the condition is true (or something else exits the journey).

Time-capped wait-until: you set a maximum hold (e.g. 3 days, 14 days). If the condition becomes true earlier, they advance on the “met” path. If the timer hits first, they advance on the “expired / not met” path (or a configured fallback).

This is not the same question as wait until event vs fixed delay—that compares signal-wait vs clock-wait. Here both sides wait on a condition; they differ only in whether a ceiling exists.

How does each mode work?

Indefinite wait-until

Profile enters the step. The engine keeps evaluating the condition. When it flips true, they proceed. If it never flips, they remain in wait—visible as “in journey” indefinitely unless a global exit, goal, or manual removal clears them.

Time-capped wait-until

Same evaluation loop, plus a deadline. Two release edges:

1. Condition true before deadline → “met” continuation.
2. Deadline first → “expired” continuation (reminder, alternate offer, or quiet exit).

Concrete Iran ecommerce / SaaS examples

Fashion ecommerce — wait until first purchase after signup

Indefinite: hold until order_completed—fine if you also have a global exit after 90 days quiet, otherwise year-old signups still sit in “awaiting first order.”

Time-capped 14 days: if they buy → thank-you / post-purchase path; if not → cart education email then leave. Ops gets a clean funnel: met vs expired.

B2B SaaS — wait until workspace invites a teammate

Indefinite makes sense when inviting a teammate is a true prerequisite for the next onboarding email—sending “team tips” early is noise.

Time-capped 7 days is better when you still want a solo-user nurture branch: met → team playbook; expired → solo tips + lighter ask.

Payment reminder — wait until invoice_paid

Prefer time-capped with short caps (24–72h) and an expired path to SMS escalation. Indefinite payment waits create forever-pending journeys and messy collections reporting.

When to choose which

1. Condition is a hard gate and false positives are worse than long waits → indefinite (plus a separate exit policy).
2. You need a measurable “gave up waiting” branch → time-capped.
3. Cap length should match product reality (cart hours/days, onboarding days, billing cycles)—not “31 days because the UI defaulted.”
4. Pair caps with clear expired creative; empty expired paths waste the design.
5. If you actually need “skip ahead when goal hits,” that may be jump-to goal vs if/else branch rather than a bare wait.

Leadara mapping (events, segments, journeys, email/SMS)

Use Leadara primitives only:

• Events / properties / segments: express the condition as a real check (order_completed, teammate_invited, segment membership, boolean property)—not a vague note in the step name.
• Journeys: wait-until step with either no max duration (indefinite) or max duration + two exits (met / expired).
• Email / SMS: met path gets success or next-step content; expired path gets nudge or alternate offer. Do not send the “congrats you did it” creative on expiry.
• Keep channel quiet while waiting unless a separate reminder journey is intentional.

Common mistakes

• Indefinite waits with no global exit → zombie “in journey” counts.
• Caps so long they behave like indefinite without an expired creative.
• Treating timer expiry as success.
• Waiting on a condition that almost never flips (bad event name, wrong property).
• Stacking indefinite waits that block later transactional needs.
• Confusing this with ranked action-path windows—those choose among competing events; wait-until evaluates one condition (see action-path first-match vs ranked window when you need multi-signal competition).

One-line takeaway

Indefinite = await condition with no TTL; time-capped = await condition OR deadline, then branch on which won.

Next step

Find one live wait-until in your journeys. Ask: what happens if the condition never becomes true? If the answer is “they sit forever,” either add a cap with an expired path or document an explicit exit policy.

FAQ

If the condition becomes true on the last second of the cap, which path wins?

Usually the condition-met path if evaluation sees it before expiry handling—confirm race behavior in a test profile.

Can I send reminders during an indefinite wait?

Only with a separate parallel journey or explicit reminder steps; a pure wait is silent.

Is time-capped the same as a fixed delay?

No. Fixed delay always waits the clock. Time-capped wait-until can finish early when the condition is met.

What if I need both “event happened” and “property true”?

Compose the condition carefully (AND/OR). Do not assume the wait UI ORs everything loosely.

Does expiry remove them from the journey?

Only if the expired branch ends or exits. Expiry can also continue into another step.

Will indefinite waits hurt deliverability?

Not directly—but long silent stages inflate active-journey counts and tempt teams to blast “stuck” users later.

How do I QA the expired branch?

Use a short test cap (minutes) on a staging journey, force non-met profiles, verify creative and metrics.

Step-by-step for growth

1. Write the condition in one plain sentence.
2. Decide: forever OK, or need an expired story?
3. If capped, pick duration with product (not UI default).
4. Draft met vs expired email/SMS separately.
5. Build in Leadara; test met-early, met-late, and never-met.
6. Watch median time-in-step and expired share for two weeks.

Versus fixed delay and event wait

Fixed delay ignores the condition. Event wait listens for a signal occurrence. Wait-until-conditions listens for state becoming true—which might be a segment flip without a new event you care about naming.

Metrics to watch

• Share met vs expired (time-capped)
• Median and p95 time-in-wait
• Count of profiles waiting > 2× expected duration (indefinite smell test)
• Unsubscribe/complaint on expired nudges

PM reporting language

Say “14-day capped wait: 38% met, 62% expired into solo nurture,” not “onboarding is slow.”

Programmer-shaped sketch

enter wait_until(condition, cap=None):
  start = now()
  loop:
    if condition(profile): advance(met); return
    if cap and now() - start >= cap: advance(expired); return
    sleep(poll_interval)

Guards: never ship indefinite without an exit policy; never ship a cap without expired creative; name the condition after real events/properties.

Acceptance tests before publish

1. Profile meets condition immediately → met path, no full wait.
2. Profile meets mid-cap → met path.
3. Profile never meets → expired path at cap (time-capped) or still waiting (indefinite).
4. Expired creative must not congratulate a success.
5. Confirm journey exits still work while waiting (purchase goal, unsubscribe).

Channel checklist

• Expired SMS: worth the fatigue, or email-only?
• Met path: transactional vs marketing tone?
• During wait: intentional silence, or scheduled nudges elsewhere?

Designing the expired branch without sounding punitive

Expired does not mean the user failed. It means your wait budget ended. Copy should offer a lighter next step—solo tips, a shorter checklist, a human help link—not “you ignored us for 14 days.”

For Iranian ecommerce, expired often maps to “still browsing” education: size guide, return policy, installments. For SaaS, expired maps to a reduced-ambition path that still teaches value without requiring the teammate invite or the second workspace.

Interaction with re-entry and frequency caps

If a time-capped wait expires into a nudge and the user later meets the original condition, decide whether they may re-enter the met path. Document it: once-only vs cooldown. Otherwise support will see “I got the give-up email and the success email a day apart.”

Ops runbook one-pager

Paste into the journey ticket:

• condition = …
• mode = indefinite | capped
• cap = … (if any)
• met channel/creative = …
• expired channel/creative = …
• exits while waiting = …

That one-pager prevents half the “why is this user stuck?” threads.

Related reading

• Wait until event vs fixed delay: pause for a signal vs pause for a clock
• Jump-to goal vs if/else branch: skip ahead on outcome vs fork the path
• Action-path first-match vs ranked window: advance on first event or wait and pick the top path