Skip to content

Health Checks & Rollbacks

If a project has a Health Check URL configured, Conveyor gates every deployment on it after activation, and automatically rolls back to the previous release if it fails.

A deployment that failed its health check and was rolled back to the previous release

On a project’s Settings page:

  • Health Check URL: an absolute URL Conveyor will GET after activation, e.g. https://example.com/up.
  • Expected Response Text (optional): if set, the response body must contain this text for the check to pass. If left blank, only the HTTP status code is checked.

Leave the URL blank to skip health checks entirely. Activation is then the last step, and the deployment succeeds as soon as every server has swapped its symlink.

The health check only runs after every server has completed the activate step. It:

  1. Waits 3 seconds after activation (a grace period for OPcache/PHP-FPM to pick up the new release before the first probe).
  2. Sends a GET request to the health check URL, with a 10-second per-request timeout.
  3. Passes if the response status is 2xx, and (if configured) the body contains the expected text.
  4. Retries up to 3 attempts total, 5 seconds apart, if a probe fails.

A pass logs Health check passed and the deployment finishes as successful. The health-check phase has an overall 2-minute budget.

If every attempt fails, Conveyor:

  1. Re-points every server’s current symlink back to the release it served before activation (the same guarded mechanism used for manual rollbacks).
  2. Marks the deployment failed, with a message noting the health check failure and whether a previous release was restored.
  3. Fires the deploy failure notification, if configured.

If this was the project’s very first deployment, there’s no previous release to restore to. The failure message notes this explicitly.

See How Deployments Work for the full six-phase flow this check gates.