Health Checks and Unhealthy Container Replacement

Health Checks

Galaxy WebApps performs automatic health checks to ensure your application is running correctly. These checks involve sending an HTTP GET request to the root endpoint ( /) of your application and expecting an HTTP 200 OK response.

Health check parameters:

Start delay: 5 seconds after the container starts.

Interval between checks: every 10 seconds.

Timeout for each check: 5 seconds.

Number of retries before marking as unhealthy: 3.

If the application fails to respond appropriately during these attempts, the container is marked as unhealthy.

Unhealthy Containers

A container is considered unhealthy when it fails to respond correctly to health checks. Common causes include:

Excessive CPU usage (approaching or at 100%).

Exhaustion of available memory (RAM).

Execution of heavy tasks that block the main application thread.

Receiving more requests than the application can handle.

The application does not return an HTTP 200 OK status on the root endpoint ( /), as expected by the health checks.

Monitoring your application's performance and adjusting infrastructure resources accordingly is crucial to maintain stability.

Nano Container Type

The Nano container type is designed for hobby projects or open-source demonstrations. Due to its limited resources, it can easily reach CPU or memory limits, especially if the application is complex or experiences higher traffic volumes.

If you're using a Nano container and encountering frequent instability warnings, consider upgrading to a more robust container type. This can significantly enhance your application's stability and performance.

Restart and Replacement Policy for Containers

In addition to health checks, Galaxy WebApps implements an automatic restart policy for containers that fail during execution, even if they haven't been marked as unhealthy. This policy operates as follows:

Automatic restart on failure: enabled.

Delay between restart attempts: 5 seconds.

Maximum number of restart attempts: 3 times.

Observation window: 30 seconds.

If a container fails repeatedly within this window, it will not be restarted automatically again.

Recommendations

Avoid running heavy tasks in the same environment that handles end-user requests.

Utilize monitoring tools to identify bottlenecks and failure points.

Scale your application horizontally (more containers) or vertically (larger containers) based on demand.

Monitor CPU and memory usage to prevent interruptions.

Ensure your application returns an HTTP 200 OK status on the root endpoint ( /) to pass health checks.

Still Experiencing Integrity Issues?

If you've verified all the above and are still encountering health check failures or container instability, please contact our support team via Live Chat. Our specialists are available to assist you in resolving these issues promptly.

Updated on: 09/05/2025