Healthchecks

Healthchecks tell Simplifyd Cloud whether your service is alive, ready for traffic, or still starting. A readiness check is what makes zero-downtime deploys possible. Liveness and startup checks restart stuck services and protect slow-starting ones.

Healthchecks are only available on Docker services.

Deployment behaviour

Whether a redeploy causes downtime depends on whether the service has a readiness check:

There is no default readiness check. To get rolling deploys, add one pointing at an endpoint that only returns success when your application can actually serve traffic.

Check types

There are three types:

When to use each type

• Startup — use when your service takes longer than a few seconds to become operational (e.g. JVM warmup, database migration on boot, loading a large ML model). Without a startup check, a slow-starting service may be killed by the liveness check before it finishes initialising.
• Readiness — use to enable rolling deployments and gate traffic. If your service needs a moment after startup before it can handle requests (e.g. connecting to a database, warming an in-memory cache), a readiness check ensures no requests are routed to it prematurely.
• Liveness — use to detect deadlocks or infinite loops. A service that is running but stuck and not accepting connections will be detected and restarted.

How healthchecks work

All healthchecks use an HTTP GET request. Simplifyd Cloud sends a GET to the configured path and port on the service. A response with an HTTP status code between 200 and 399 is a success; anything else — including no response or a refused connection — is a failure.

The liveness and readiness checks follow this evaluation cycle:

1. Wait Initial Delay seconds after service start before the first check.
2. Send an HTTP GET request every Period seconds.
3. Allow each request Timeout seconds to respond.
4. After Failure Threshold consecutive failures → take action (restart for liveness; stop sending traffic, for readiness).
5. After Success Threshold consecutive successes → mark the check as passing again.

The startup check runs through the same cycle; once it passes for the first time, it stops running and the liveness and readiness checks begin.

Configuring healthchecks

1. Open the service panel → Settings tab → Deploy section.
2. Find Health checks. Each of Liveness Probe, Readiness Probe, and Startup Probe is listed with its own button.
3. Click + Add next to the check you want.
4. Fill in the dialog:
   • Path — the HTTP path your service exposes for health (e.g. /health, /ready, /livez).
   • Port — the port your service is listening on (e.g. 8080).
5. Optionally expand Advanced settings to configure timing and thresholds (see below).
6. Click Save Probe.
7. The check is staged as a pending change. Click Apply in the Apply Changes bar to deploy.

Advanced settings

Editing and removing healthchecks

• Edit — click the pencil icon next to the check to reopen the dialog with the current values pre-filled.
• Remove — click the trash icon next to the check. The removal is staged and applied on the next deployment.

Recommended health endpoint

Your service should expose a lightweight endpoint (e.g. GET /health) that:

• Returns HTTP 200 when the service is ready.
• Does not make external calls (database, third-party APIs) unless you specifically want those to gate readiness.
• Responds quickly — within the configured timeout (typically 1 second).

A minimal example in Node.js:

app.get('/health', (req, res) => res.sendStatus(200));

For a readiness check that also verifies the database is reachable:

app.get('/ready', async (req, res) => {
  try {
    await db.query('SELECT 1');
    res.sendStatus(200);
  } catch {
    res.sendStatus(503);
  }
});

Common patterns

Web app with a slow startup

Use a startup check with a generous window, then readiness and liveness for ongoing health:

Minimal setup — traffic gating only

If you only need rolling deployment and traffic gating, a readiness check alone is sufficient: