Healthcheck Path

A healthcheck path allows the platform to periodically verify that your application is running and functioning correctly.

By default, during deployment the system checks only the root URL (/). It sends a request to the main page, and if the response status is not in the 2xx range, the deployment is considered unsuccessful.

However, this behavior is not always suitable:

• An API may not have a root endpoint and may return 404.
• A static site may rely on client-side routing, and the root path may not work without a browser environment.
• An application may temporarily return an error while waiting for external resources (e.g., a database or third-party service).
• After deployment, the application is not monitored by default; even if it becomes unreachable later, its status will not change.

To avoid these problems, you can configure a custom healthcheck path. This requires the application to expose an endpoint that does not depend on external systems and reliably reflects the application’s state.

Common examples include: /health, /status, or /ping.

How Healthchecks Work

Healthcheck requests are always made from localhost.

The only requirement is that the endpoint returns a 2xx status code. The response body is ignored.

During Redeployment

If a healthcheck path is specified, the system performs a sequence of checks against the new deployment:

1. The system sends three consecutive requests to the healthcheck endpoint.
2. If all three return 2xx, the deployment is marked successful, and the new version becomes active.
3. If all three return a non-2xx code, the deployment is marked unsuccessful, and the previous version keeps running.

Healthchecks continue until one of these conditions is met:

• three successful responses in a row,
• three failed responses in a row,
• 180 seconds have passed.

If neither success nor failure is determined within 180 seconds, the deployment is marked unsuccessful.

Deployment logs will contain a message if a healthcheck fails.

After Startup

Once a deployment succeeds, the system continues to check the application's health with one request every 30 seconds.

If three consecutive checks fail, the application is automatically restarted. This event will appear in the application logs.

Configuring a Healthcheck Path

You can configure a healthcheck path when creating a new application or later for an existing one.

When Creating an Application

In the App settings section, enter the desired path in the Health Check path field.

For example, if your application provides a /health endpoint accessible at https://domain/health, set:

/health

For an Existing Application

1. Open the application in the control panel.
2. Go to the Settings tab.
3. In the Deploy settings section, click Edit.
4. Enter the healthcheck path.
5. Click Save Data.

A new deployment will automatically be triggered with the updated setting.

Docker and Docker Compose

Dockerfile Deployments

If your application is deployed via a Dockerfile, you can still configure the healthcheck path in the control panel.

However, if the Dockerfile includes a HEALTHCHECK instruction, it takes precedence, and the control panel setting is ignored.

Example:

HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
  CMD curl -f http://localhost/health || exit 1

For more details, see the official Docker documentation.

Docker Compose Deployments

For Docker Compose deployments, configuring the healthcheck path in the control panel is not supported.

If your services use a Dockerfile, you may configure HEALTHCHECK directly inside it—it will behave as described above.