I know this is an old post, but I did not see any other answers, so here is something I learned:

I ran into a similar situation after modifying the 'Global' deployment zone's address in Service Center from a deployment controller's IP address to the fully qualified domain name (FQDN) of the load balancer that sits in front of our servers to align with OutSystems best practices.

Since our load balancer employs SSL offloading for incoming requests, we had to configure three additional settings in Service Center:

• Under Administration -> Security -> Network Security, we had to ensure that Internal Network Addresses included the IP addresses/ranges of the deployment controller, front-ends and monitoring tools. 
• Also under Administration -> Security -> Network Security, we had to ensure that the IP address(es) of the load balancer were included in the list of Trusted Proxy Addresses.
• Finally under Administration -> Deployment Zones we had to enable HTTPS for internal communications on our deployment zone settings.

This last bullet was the missing the missing puzzle piece. Our load balancers redirect all HTTP requests to HTTPS requests via a 301 redirect. Unfortunately, if HTTPS for internal connections is not enabled, things like timers and automatic process activities can fail because, from what I can tell, the scheduler service appears to reference the deployment zone address whenever firing off a message to one of the front ends. Moreover, the scheduler does not appear handle 301 responses. 

Therefore, if the deployment zone is something like an IP address whose machine expects an offloaded request, internal HTTPS requests should not be used. This was our original case.

After pointing the deployment zone address to the FQDN of our environment, which hits a load balancer expecting an HTTPS request, we had to enable HTTPS for internal communications on our deployment zone settings to avoid the 301 issue.