A 502 occurs when our proxy cannot get a response from your application, which can happen even while the container is running if the application process becomes unresponsive (e.g., under heavy load or resource exhaustion). Your logs show significant bot/scanning traffic (WordPress probes, .env scanning, encoded path probes) with some requests already receiving 429 responses, which could contribute to the application becoming temporarily unable to respond. Regarding healthchecks, they are only used at deployment time to verify the new version is healthy before routing traffic to it - they are not used for continuous monitoring and will not restart a running container. For ongoing uptime monitoring and automatic restarts, you would need an external tool like Uptime Kuma combined with a restart policy set to handle failures. You can also check the Metrics tab in your service panel to see if CPU or memory spiked during the periods when 502s occurred.