CF Scheduler states script ran, but data was not changed and original output log was not modified.

Rick, can you update us on the status of things? BKBK and I have offered different takes on where you may find either the problem or a solution or a clue toward either.  If the problem remains somehow and you can let us know any new info, we may be better able to help you get to a solution.

Most probable cause: an error or shortcoming in the CFM file.

If you share the code we will be able to give you feedback.

Rick, there can be many issues, and what you share may not be enough info to solve things readily.

There are a few additional diagnostics that may help, and I offer a couple of guesses while we await a reply (or someone else may offer a different guess that's right).

Gathering diagnostics 

First, when you say, "I also created a cfoutput log to print that it has started", do you mean that cfoutput is in your autocompletewos.cfm file you're calling? And you're saying that the empty log suggests to you that code did not run?

There's also a feature with each scheduled task to have its output (if any) saved to a file (which is overridden on each task execution). Have you enabled it, or can you? What does it show? 

Next, you list the line from the http.log showing the task's url being called. That log should also show when a task (or cfhttp) ends. Do you ever see that?

Finally, is there anything in the scheduler.log? If you have, that can be enabled on the cf Admin logging settings page (not the scheduled tasks page, as some might expect). If you enable it, what does it show when you run this task? 

Also, what cf version is your cf where you have defined the scheduled task? And what update of the cf version? And as for the url you're calling, since that's a cf page, do you know its version and update level? 

Trying cfhttp instead of a task 

Second, if none of the above seem to help, the next step is to create a test cf page (to run from that same cf server running the task) and have it do a cfhttp to the same url as the one in the task, as simple as <cfhttp url="https://yoururl">, or the script equivalent if you prefer.

After that, do a <cfdump var="#cfhttp#">. What does it show? There may be useful clues. (Under the covers, a cf scheduled task does in the end up doing basically the same thing as a cfhttp. But what you may see in that CFHTTP could show more error detail than is tracked for a task.) 

Note also how this is quite different from just running the URL in a browser, for reasons I'm about to discuss. But then again, that's another useful diagnostic: if you run the URL in a browser ON THE SERVER where the scheduled task is defined, are you confirming that works fine? (Running it from OFF the server is again not technically the same.)

What may be amiss: inability to call the url

Any of these diagnostics for the task may show first a failure to successfully CALL the url as a task. That can have many explanations. Since your log shows it's an https call, perhaps you need simply to update the jvm that Cf uses. I have a blog post with more on that :

https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/

And sometimes you may need to import a certificate for the called server into the certificate store of the jvm cf is using. But I'd consider the jvm update first, because if that solves it, that solves the bigger problem of being on a dated jvm. See my post for more, including more on how to do it, and how to deal with possible mistakes in trying it. 

Along the same lines, the problem could be that someone DID update the jvm cf uses...to a version above Java 11.0.11. That changes the jvm to not be able to call out via https/tls to servers unless they support at least tls 1.2. Maybe the server you're calling in the task (which may well be your own) doesn't yet support tls 1.2 (though it has been out for several years). While updating the server being called is one solution, another is to tweak the jvm to ALLOW calling such "old" servers. I cover that in a blog post from when this jvm behavior changed started last April:

https://www.carehart.org/blog/2021/4/26/new_java_updates_for_Java_8_and_11_as_of_Apr_2021

As I note in those posts, I can help people do such things quickly (update the jvm cf uses, and/or tweak it to support calls to tls1.1 or 1.0) via remote consulting. 

What may be amiss: the task may be exceeding a timeout

Finally, a last possibility is that the task IS starting and the called url IS running--but you may be hitting a timeout limit. Some have reported they experience a situation where the underlying quartz open source project (which cf uses to manage scheduled tasks) "misfires" the task if it takes longer than 60 seconds. Again, if that's the case, you should see some output to that effect in the various means I list above.

And do you have any timeout set in the task (there's a field in the task definition)?

Again, though, the cfhttp I propose above should also show if the URL called is taking long to run. 

If that's what's happening, then as for the task failing in calling it, again let's hear what cf version and update you're on. I've not been able to recreate the problem on the latest updates to cf2021, 2018, or 2016. BTW, note that that request WILL run and WILL finish. It's just the sched task that will seem to fail.

But this goes back to the first question I asked: is the cfoutput you do in that page you are calling? If it is, and it's not producing that output, then we're back to wondering if the request DOES ever start which is what the rest of my note covers.

Sorry it was a long one. Let us know what you find.