> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Wait and Repeat

> Delay workflow execution, repeat actions on a schedule, and set stop conditions in Rootly that control when a repeating workflow ends or pauses automatically.

## Overview

Workflows support two scheduling controls that can be used independently or together:

* **Wait before executing** — delays the start of actions after a workflow is initiated
* **Repeat every / Repeat on** — re-runs the workflow's actions on a recurring schedule after the first execution

These controls are most commonly used to build reminder workflows, periodic status update messages, and escalation nudges that fire at regular intervals during an incident.

***

## Wait Before Executing

A wait delays the start of actions after the workflow's trigger fires and run conditions are satisfied.

**Available wait durations:** 30 seconds, 1 minute, 2 minutes, 5 minutes, 1 hour, 1 day, 3 days, 1 week, 2 weeks, 1 month.

<Note>
  The shortest selectable wait in the UI is **30 seconds**. The underlying validation accepts any value down to 10 seconds, but the predefined options start at 30 seconds. Rootly re-evaluates run conditions after the wait period elapses. If conditions are no longer satisfied at that point, the workflow stops without executing actions.
</Note>

### Execution flow with a wait

```
Trigger fires
  → Run conditions checked → fail → stop
  → Run conditions pass → wait
  → Run conditions re-checked → fail → stop
  → Run conditions pass → actions execute
```

This means a workflow that was eligible when it triggered can still be stopped before it acts if the situation has changed during the wait window — useful for "if still unresolved after 30 minutes" patterns.

***

## Repeat Every

**Repeat every** sets the interval between successive executions after the first run. Each repeat cycle re-checks run conditions before executing actions, so the workflow naturally stops repeating when the conditions are no longer true.

**Available repeat intervals:** 10 minutes, 30 minutes, 1 hour, 1 day, 5 days.

### Repeat on (day-of-week filter)

**Repeat on** restricts repeats to specific days of the week. Select any combination of days. Repeat cycles that fall outside the selected days are skipped.

| Day       | Code used internally |
| --------- | -------------------- |
| Sunday    | S                    |
| Monday    | M                    |
| Tuesday   | T                    |
| Wednesday | W                    |
| Thursday  | R                    |
| Friday    | F                    |
| Saturday  | U                    |

<Tip>
  Use **Repeat on** with a **1 day** interval to build weekday-only reminder workflows without needing separate conditions for weekends.
</Tip>

### Execution flow with repeat

```
Trigger fires
  → Run conditions checked → pass
  → Wait (if configured) → Run conditions re-checked → fail → stop
  → Run conditions pass → actions execute
  → Stop-repeat conditions checked → any match → stop
  → Wait for repeat interval
  → Run conditions re-checked → fail → stop
  → Run conditions pass → (wait if configured) → Run conditions re-checked → fail → stop
  → Run conditions pass → actions execute
  → … continues until a stop condition is met
```

***

## Stop Repeat Conditions

Without explicit stop conditions, a repeating workflow continues indefinitely as long as run conditions remain true. Stop repeat conditions give you precise control over when repeating ends.

Any one of the following conditions stopping the loop:

<ParamField body="Maximum number of repeats" type="integer">
  The workflow stops after executing this many times. Accepts values from **2 to 100**.

  Use this when you want a fixed number of reminders regardless of how long the incident stays open.
</ParamField>

<ParamField body="Time since first run" type="select">
  The workflow stops once this much time has elapsed since the first execution. Options: **10 minutes, 30 minutes, 1 hour, 1 day, 5 days**.

  Use this to cap the reminder window — for example, stop sending updates after 1 day even if the incident is still active.
</ParamField>

<Warning>
  Stop repeat conditions are evaluated using OR logic — the workflow stops as soon as any single condition is met, not when all conditions are met.
</Warning>

***

## Common Patterns

<AccordionGroup>
  <Accordion title="Reminder every 30 minutes for up to 1 hour" icon="bell">
    Configure:

    * **Repeat every:** 30 minutes
    * **Time since first run:** 1 hour
    * **Run condition:** incident status is not Resolved

    The workflow sends a reminder at 0, 30, and 60 minutes and then stops — or stops earlier if the incident resolves.
  </Accordion>

  <Accordion title="Daily status update on weekdays only" icon="calendar-days">
    Configure:

    * **Repeat every:** 1 day
    * **Repeat on:** Monday, Tuesday, Wednesday, Thursday, Friday
    * **Run condition:** incident is still active

    The workflow fires once per weekday and skips Saturdays and Sundays automatically.
  </Accordion>

  <Accordion title="Delayed escalation if still unresolved" icon="circle-arrow-up">
    Configure:

    * **Wait:** 30 minutes
    * **Run condition:** incident severity is P1 and status is not Resolved

    The workflow initiates when a P1 opens, waits 30 minutes, re-checks whether it is still open and still P1, then fires the escalation action. If the incident resolved during the wait, no action is taken.
  </Accordion>

  <Accordion title="Single reminder with a grace period" icon="hourglass-half">
    Configure:

    * **Wait:** 1 hour
    * No repeat

    The workflow fires once, one hour after the trigger, as long as run conditions still hold. Useful for a one-time follow-up nudge without building a full repeat loop.
  </Accordion>
</AccordionGroup>

***

## Troubleshooting

<AccordionGroup>
  <Accordion title="My workflow stopped repeating earlier than expected" icon="circle-question">
    The most common cause is run conditions becoming false. Rootly re-evaluates run conditions before every repeat cycle. If the incident moved to a status, severity, or field value that no longer satisfies the conditions, repeating stops.

    Check the workflow run history to see which condition evaluation caused the stop. Also verify that no stop repeat condition (max repeats or time since first run) was reached.
  </Accordion>

  <Accordion title="My workflow ran once but never repeated" icon="circle-exclamation">
    Confirm that **Repeat every** is set. A wait-only workflow (no repeat interval) executes once after the delay and does not loop. Also check whether a stop repeat condition was already satisfied after the first run — for example, a **Maximum number of repeats** of 2 means the workflow runs twice total (the initial run plus one repeat).
  </Accordion>

  <Accordion title="Actions fired even though conditions should have prevented them" icon="triangle-exclamation">
    Conditions are checked at trigger time and again after any wait period, but not continuously during the wait. If conditions briefly become false and then true again during a wait window, the post-wait check is what matters. Design conditions around the state you care about at execution time, not the state at trigger time.
  </Accordion>
</AccordionGroup>