A delay tells Krom Automation to wait before running the first action in a workflow. Instead of reacting to an event the instant it fires, the workflow pauses for a set amount of time and then continues.

Delays are simple to configure but have real impact on how your automations feel and perform.

Where delays are configured #

You set a delay on the trigger node itself, not on individual action nodes.

Open your workflow on the canvas and click the trigger node. In the configuration panel on the right, find the Delay section. Enter a number and choose a unit: minutes, hours, or days.

The delay applies to the entire workflow. When the trigger fires, Krom Automation schedules the workflow to run after the delay period. All actions in the workflow run after that scheduled time, in sequence.

If you set no delay, the workflow runs immediately when the trigger fires.

Available delay units #

Unit	Free	Pro
Minutes	Yes	Yes
Hours	Yes	Yes
Days	Yes	Yes
Weeks	No	Yes

Krom Automation Pro adds week-length delays, useful for re-engagement sequences, subscription renewal reminders, and campaigns timed several weeks after an initial event.

How delays work under the hood #

Delays in Krom Automation run on Action Scheduler, the same background job library that WooCommerce uses for its own scheduled tasks.

When the trigger fires, Krom Automation creates a scheduled job with the execution time set to now plus the delay. Action Scheduler stores this job in the database and processes it at the scheduled time using WordPress Cron.

Your site does not need to be visited or loaded during the delay period for the job to run. As long as WordPress Cron is enabled on your host, the delay will execute reliably. On busy sites, Action Scheduler handles large queues of delayed jobs without slowing down the front end.

When to use a delay #

Welcome emails

A 10-minute delay on a user registration workflow makes the welcome email feel more personal and less like an instant bot reply. It also gives the user time to explore your site first.

Review requests

Trigger a review request email 7 days after an order is completed, not immediately. You need a 7-day delay (or a 7-day delay in Krom Automation Pro using weeks).

Renewal reminders

Send a subscription renewal reminder 30 days before expiry by using the WooCommerce Subscriptions “Trial Ending” trigger (Pro) with an appropriate delay.

Follow-up sequences

Build a multi-step follow-up by combining one workflow with a delay on each action. Or create separate workflows that trigger at different points in a user journey.

Inactivity alerts

Use the Schedule trigger (Krom Automation Pro) to run a workflow periodically that checks for users who haven’t logged in, rather than reacting to a single event.

A note on WordPress Cron #

Krom Automation’s delays depend on WordPress Cron being active on your server.

Some managed hosts disable standard WordPress Cron (WP-Cron) and replace it with a real server cron. This is actually better, because server cron runs on a fixed schedule rather than only when your site is visited. If your host uses server cron, delayed workflows will execute more reliably and more punctually.

If you’re unsure whether WP-Cron is enabled, check Tools > Site Health > Info or contact your host. You can also install a plugin like WP Crontrol to inspect your scheduled jobs queue and confirm Krom Automation’s delayed jobs are appearing there.

What happens if a delay fails #

If a delayed job doesn’t execute (for example, because Cron was temporarily disabled), Action Scheduler retries it automatically. Jobs don’t silently disappear.

You can check the status of pending and completed jobs in Krom Automation > Logs. Each execution record shows when the workflow was scheduled, when it actually ran, and the status of every step.

Delays and run control together #

When you use Run once per entity combined with a delay, Krom Automation locks the entity as soon as the trigger fires, not when the delayed job runs.

This means if a user registers and your workflow has a 10-minute delay, the run-once lock is applied immediately at registration. Even if the trigger fires again for the same user within those 10 minutes, the second execution is skipped before it reaches the delay. The first scheduled job will still run at the 10-minute mark as intended.