Support

Nothing is wrong on the backup engine's side. WebCRON just stops telling it to continue. I believe you just need to increase the allowed time for that CRON job in WebCRON's site. 

I can see when it starts and when it stops. 

The start is this:

--- START OF RAW LOG --
DEBUG   |20261028 14:57:32|*** Batching successive steps (nesting level 1)
DEBUG   |20261028 14:57:32|====== Starting Step number 1 ======

The end is this:

DEBUG   |20261028 15:05:10|Kettenrad :: Domain object returned without errors; propagating
DEBUG   |20261028 15:05:10|Kettenrad :: Break flag status: YES
DEBUG   |20261028 15:05:10|----- Finished operation 145 ------
DEBUG   |20261028 15:05:10|Successful Smart algorithm on Akeeba\Engine\Core\Domain\Pack
DEBUG   |20261028 15:05:10|====== Finished Step number 34 ======
DEBUG   |20261028 15:05:10|Kettenrad :: Setting the break flag between domains
DEBUG   |20261028 15:05:10|*** Engine steps batching: Break flag detected.
DEBUG   |20261028 15:05:10|*** Batching of engine steps finished. I will now return control to the caller.
DEBUG   |20261028 15:05:10|No need to sleep; execution time: 22486.148118973 msec; min. exec. time: 0 msec
DEBUG   |20261028 15:05:10|Saving Kettenrad instance frontend

As you can see, there is really nothing wrong on the server side of things. It is progressing just fine, it has finished saving the engine state and sent the redirection back to the caller. This means it's not an issue with our code. You can also see that we are currently in step 34, so it's not a matter of not having set up WebCRON to follow redirects (it would have stopped either at step 1 or step 20). Since 34 steps have run it's not a matter of something messing up the output of your site, breaking the redirection; it would have stopped at step 1. Likewise, it does not seem that it is a problem with your host blocking WebCRON, or it would not have started at all.

That's why I told you to check the timeout on WebCRON, but that's also fine.

You will have to ask WebCRON to check why it stopped following the redirects. It's either a problem on their end, or something on your host blocks the request from being served back to WebCRON (or WebCRON following the redirect). Since the problem is something between WebCRON and your host I have no visibility into it.

That could indeed be very pertinent to your issue. In many cases hosts are applying deliberate limits for repeated requests to the same URL from the same IP. This is usually a good security posture, but it doesn't work for URLs meant for automation. The frontend backup URL is one of them.

Between you saying that this has only started happening the last few days, and confirming that Infomaniak did "some changes lately" I am wondering if maybe they did something like that as part of their strategy to mitigate PHP2Shell, the (already patched...) vulnerability in PHP which received a disproportionate amount of publicity for no good reason. I can imagine the extent of (mostly asinine) questions they must've received about it and how that may have led to an overcorrection towards failing closed (blocking things when unsure). It's worth asking them to whitelist the URLs related to the frontend backup, and ask them if there's anything else that might be blocking backups through WebCRON. The fact that you have years of evidence that this is an intended feature on your sites would possibly make it easier to convince them to help you.

That's even better!

My experience with commercial hosting is that when they do not support proper command-line CRON their web-based pseudo-CRON is very much crippled with execution time limits, or not supporting redirections (either not enough, or at all). Seeing a host which allows web-based pseudo-CRON to work properly is quite rare. I am now mentally filing Infomaniak as a host which has a properly working web-based pseudo-CRON implementation.