I find that mashing the retry button makes no real difference, as although some files come in faster, there are always one or two stragglers that take days to come in, no matter what I do. Also, I have multiple hosts, three of which are headless, so retry button mashing is not very practical. IMHO, adjusting the deadline by several days to compensate for the slow download seems like the best workaround. Does anyone have a better idea?

Based on the detail provided by alanb1951 and without any detailed knowledge of their infrastructure, it appears that they run out of instances to service requests, or these services are not really ready when the connection is made.

I would hope that they are not dispatching new instances when the request arrives and are relaying to a worker pool. There could be an issue with scaling the pool for current request rate. Here, it is possible that new workers are not added fast enough and a given request has nowhere to go. It is also possible that the worker is added to the pool before it is actually able to handle the request.

Another possibility is that there is a backend resource the get exhausted, and that is the source of the 503. This would be similar to the first case, just a layer deeper in the stack.

I suspect the key is to reliably determine when the resource is truly ready, and only dispatch requests to those instances. In many situations, this is non-trivial and the dynamic nature of the environment does not help.

It's acknowledging receipt of results, and accumulating points in the Boinc app, but not showing any on the front screen for the days of the week.. Not even a list of devices.

sometimes it's a big list that I have to spend a long time refreshing for them all to flush through...

Ah well, manual massaging or batch file massaging, without any of that, there will not be any new files downloaded, only this from BOINC:
"Not requesting tasks: some download is stalled"

So far today, I've managed to massage down a couple of hundred OPNG tasks.