Healthcheck Path

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

By default, if no health check is enabled, the platform performs only a basic check after deployment: it makes sure that the application’s container has started successfully. In this case, the actual application health is not evaluated—the app may be responding incorrectly or not responding at all, yet the deployment will still be marked as successful.

To prevent this, you can configure a health check path. Your application must expose an endpoint that does not depend on external systems (such as a database or third-party services) and accurately reflects the application’s internal state.

You can specify this endpoint during configuration: for example, /health, /status, or /ping.

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.

How Healthchecks Work

Copy link

Healthcheck requests are always made from localhost.

The only requirement is that the endpoint returns a 2xx status code. The response body does not matter; only the status code does.

During Redeployment

Copy link

If a healthcheck path is configured, the system sends up to three consecutive GET requests to the new application instance.

• If at least one request returns a 2xx status code, the deploy is considered successful, and the new version becomes active.
• If all three attempts fail (any status code other than 2xx), the deploy is marked as unsuccessful, and the previous version remains active.

Health checks continue until one of the following conditions is met:

• a single successful response,
• three consecutive failed responses, with the last one occurring 40 seconds after startup,
• or 180 seconds elapse; if none of the above occur within this time, the deploy is considered unsuccessful.

If the check fails, a health-check failure message will appear in the deployment logs.

After Startup

Copy link

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

Copy link

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

When Creating an Application

Copy link

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

Copy link

1. Open the application in the Hostman dashboard.
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

Copy link

Dockerfile Deployments

Copy link

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

However, if the Dockerfile includes a HEALTHCHECK instruction, it takes precedence, and the dashboard 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

Copy link

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

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