Power Automate Delay vs Delay Until: When to Use Each Action

Use Delay when the flow should pause for a relative period, such as 10 minutes. Use Delay Until when it should resume at a particular UTC timestamp, such as 2026-09-18T14:00:00Z.

Neither action is a reliable cure for a race condition. If the flow needs to wait until another system is genuinely ready, check that condition and retry within a defined limit.

Fact-checked against current Microsoft documentation on 24 August 2026.

Delay and Delay Until compared

Action	Input	Good use	Poor use
Delay	A count and unit	Pause for a known relative interval	Guess how long an external process needs
Delay Until	A UTC ISO 8601 timestamp	Resume at a stored deadline	Assume a local date has the right time zone

Both actions keep the same cloud-flow run alive. Microsoft currently limits a single cloud-flow run to 30 days, including time spent waiting. Run-history retention is also 30 days, but it is a separate limit.

How to use Delay

1. In the Power Automate designer, select the plus button where the pause should occur.
2. Search for Delay under the built-in Schedule actions.
3. Enter a count.
4. Select the unit shown by the action.
5. Save and test the flow.

A reasonable example is a short, documented pause before an eventual-consistency check. Even then, the next action should confirm that the required record or file exists.

Do not use Delay as blind fault handling

This pattern is fragile:

1. Start document generation.
2. Delay for 30 seconds.
3. Email the document.

It works only when generation always finishes within 30 seconds. A busy service can take longer, while a fast service makes most of the wait unnecessary.

A safer pattern is:

1. Start document generation.
2. Check whether the output exists or whether the job status is complete.
3. If it is not ready, wait briefly and check again.
4. Stop after a defined number of attempts or a deadline.
5. Record and notify the failure.

Use the connector's retry policy for transient HTTP failures. Use a bounded Do until only when you can query a real readiness condition. Never create an unlimited polling loop.

How to use Delay Until

1. Add Delay until from the built-in Schedule actions.
2. Supply a timestamp in UTC ISO 8601 format.
3. Save and test with a near-future time before using a business deadline.

Microsoft documents the expected shape as:

YYYY-MM-DDThh:mm:ssZ

For example:

2026-09-18T14:00:00Z

The Z means UTC. A SharePoint date value may look similar, but you must still know whether it represents a date-only value, a local time or a UTC timestamp. Do not drop it into Delay Until without checking the run output.

Convert a local business time to UTC

Suppose a list stores a local appointment time. Convert it before the delay rather than relying on the flow owner's regional settings.

Power Automate provides the Convert time zone action and workflow expression functions including convertToUtc(). Microsoft warns that connectors can display time zones differently, so inspect the actual trigger or action output during testing.

Be especially careful around daylight-saving changes. A hard-coded offset such as +01:00 does not represent London time throughout the year. Use a named source time zone in the conversion action.

What if the timestamp is already in the past?

Add a condition before Delay Until:

greater(<target timestamp>, utcNow())

If the target is in the future, wait. If it is already due, continue immediately or send the item to an exception path. This makes the behaviour explicit and easier to audit.

Do not wait more than 30 days in one run

Because the maximum cloud-flow run duration is 30 days, a 45-day Delay Until is not a valid design. A wait close to the limit also leaves little room for the trigger and later actions.

For longer schedules:

1. Store the target date and workflow status in SharePoint, Dataverse or another durable data store.
2. Run a scheduled flow at an appropriate interval.
3. Query only records that are due and not already processed.
4. Claim or mark each record before sending to avoid duplicates.
5. Record completion and any failure.

Microsoft recommends a similar two-flow pattern for approvals that may run longer than 30 days, with the approval state stored in Dataverse.

Common mistakes

The action says the timestamp is invalid

Inspect the value in run history. Confirm it is a complete ISO 8601 timestamp and has been converted to UTC.

The flow resumes at the wrong local time

The source value was probably interpreted in a different time zone. Convert from the named business time zone to UTC before Delay Until.

The flow still fails after a short Delay

The delay did not prove the dependency was ready. Replace the guess with a status check, bounded polling or the connector's retry policy.

A long-running flow disappears or times out

Check the 30-day run-duration limit. Redesign long waits as stored state plus a scheduled flow.

Several runs resume together

This can create duplicate or conflicting updates. Use trigger conditions, idempotency markers and appropriate concurrency settings. Do not assume a timer provides locking.

A practical design rule

Ask one question before adding either action: am I waiting for time, or waiting for evidence?

• If you are waiting for time, use Delay or Delay Until.
• If you are waiting for evidence, check the system that owns the evidence.
• If the wait can exceed 30 days, store state and start a later run.

Microsoft sources

• Pause workflow execution with Delay and Delay Until
• Power Automate limits and configuration
• Convert a time zone in Power Automate
• Modern approvals and long-running approvals

Improve the flow before it reaches production

Bring the timing requirement and a sample run to the Power Automate Builders Space. This attributed link lets us measure whether the recommendation helps readers continue the job.