Are there any advantages of using the Async Gateway over schedule tasks. For example, when sending the same request at intervals? They both ultimately can do the same thing, but is the gateway more efficient? Thanks!

if you are basically wanting to run a job at a predictable schedule, there is no difference. If you need the job to run immediately based on input from another source, then the gateways would be more appropriate. For example, I had a situation where I wanted to import flat files as soon as they arrived, so a gateway made more sense as opposed to running a scheduled job every minute. The gateway would only log things based successful file imports or failures, where as a scheduled job would have been full of logs showing "no file found" errors which would not be great for checking things.

You have more control over with a gateway but takes a bit more effort, a scheduled task is more rigid but easier to setup Performance wise, a gateway is a long running thread, which sleeps, so it's a tiny bit more efficient but that shouldn't be a major consideration. In my experience, I have had scheduled break as they are going over the network

There is one other issue w/ scheduled tasks if you are using IIS : the automatic restarting of the IIS app pool that has a default iteration of every 29 hours. If you have a long running scheduled task, you will get some funky results. A gateway should work outside of that. Here is an article I wrote about it for more info https://wris.com/blog/2025/03/20/gremlins-in-the-machine-the-potential-impact-of-iis-app-pool-recycling

Thanks guys. My solution was to create a microservice (Lucee docker container) dedicated to running gateway events. This service also records each event and queries the results as a monitor. I'm thinking this solution is probably the most reliable... at least from my experience. And since it is on Linux, I'm not affected by pool recycling as you mentioned.

glad you got a solution that will work