Skip to main content

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.

​
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.
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.

​
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.
DayCode used internally
SundayS
MondayM
TuesdayT
WednesdayW
ThursdayR
FridayF
SaturdayU
Use Repeat on with a 1 day interval to build weekday-only reminder workflows without needing separate conditions for weekends.

​
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:
​
Maximum number of repeats
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.
​
Time since first run
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.
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.

​
Common Patterns

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.
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.
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.
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.

​
Troubleshooting

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.
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).
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.