How to Delay Workflows for 3 hours?

I found this article but am running into issues for Workflow delays longer than 30 minutes. In particular, my workflow is timing out with the following error: "The workflow run exceeded the timeout of 900000 ms"

In particular, I've set up a simple async function (code5) as suggested in the above response:

const DELAY = 10800000 // 3 hours
async function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); }

However, the problem is that query5 depends on the value in an earlier step, query1, in the workflow that is executed before code5 is run. That is,

query1 --> code5 --> (I want a 3 hour delay here) --> query5 --> ...

When I try to connect the components, connecting query1 to query5 causes it to skip the intermediary code5 step entirely!

How would I get code5 to delay for 3 hours, before continuing on in the workflow?


Hi @Jeffrey_Yu thanks for asking. Can you tell me more about the need for a 3 hour delay? Do you need one of the steps in your workflow to start a job that takes 3 hours to run? Are you hitting an external API, or processing something in memory?

I wonder if leveraging webhooks to chain your workflows could help. Every workflow has a webhook. You can trigger a webhook from within a workflow. So, if you call a webhook trigger to call the second workflow once the first one is done, that might be the best setup to chain these tasks to run. So I'd recommend breaking this out into two different workflows, and use the "workflow" block type to trigger the webhook of the second workflow.

In terms of a block within your workflow that's taking longer than 10 minutes (sounds like it takes about 3 hours?) I don't think that's going to be possible to work around. Perhaps breaking this out into even more discrete steps could help here, but blocks are held to a 10 minute timeout, which is what it looks like you're running into:

Based on where we land here, I can also update that previous topic you linked in case there's additional nuance or considerations that should be called out there.

Hi! I’m building a 3 hour delay because we are using retool to process sales leads. After our students fill out a background form, we want to give them the impression that we read took some time to read through their answer (3 hours, that is) instead of automating an instant response. This way, we can still read the background form instantly, but the student won’t be notified until later.

Thus, once the trigger from the website arrives (the background form submitted), the workflow should add the student immediately, but just wait 3 hours before actually executing one particular task: sending the email.

The point about chained web flows makes sense! How would I add a delay so that the second workflow (which contains just an email step) only executes after a 3 hour delay?

What about if you made a schedule table, that stores trigger times?

So, workflow 1 does query1 -> code5 -> TIME_NOW_PLUS_3_HRS -> schedule_db

Then have a second workflow on a schedule to run, every 15m? This will check the schedule table and if the action time has passed the current time, then workflow 2 can call / finish with schedule_db -> query5 -> etc

1 Like

Ohhh. so to clarify, you're proposing:

(1) change workflow one so that after running code5, it will then upload a specific time, TIME_NOW_PLUS_3_HRS to a database table called 'schedule"

Then, the second workflow will run every 15 minutes, and grab the most recent entry from the "schedule" table. If the most recent time has passed the current time, then it will move forward with the execution of query5 onwards?


Yeah. Were going to use the database as a queue.

The first workflow will push onto the queue (insert to db) with their next execution time.

Then the workflow on the schedule will keep querying the queue table, and as it pulls from it, it can either skip the run if the time hasn't passed, or continue and pop that record off the queue (delete the row)

You could even make 3 workflows:
One to push onto the queue, one to check the queue, and one to do the queue's actions.