---
title: "Set up health checks"
description: "Choose how a TIR Auto Scaling Group decides a VM is unhealthy, add an optional HTTP or TCP check, and know what happens to a VM that fails."
content_type: "how-to"
product: "tir-auto-scaling"
platform: "TIR"
url: "/tir/tir-auto-scaling/how-to/set-up-health-checks/"
topic: ["scale"]
---

# Set up health checks

An Auto Scaling Group replaces a VM that is unhealthy, so the group keeps its size. Every group checks
its VMs and hosts. You can add a check of your own application over HTTP or TCP, which makes the group
replace a VM whose application stops answering.

## Before you begin

- An Auto Scaling Group, or the **Create Auto Scaling Group** form open. See [Create an Auto Scaling
  Group](/tir/tir-auto-scaling/how-to/create-an-auto-scaling-group/).
- For an HTTP or TCP check, the port, and for HTTP the path, that your application answers on.

## Choose a check

Health settings are in **Advanced Settings**, under **Health & recovery**, on the create form and on
**Edit Auto Scaling Group**.

**Infrastructure health checks** are always on: the group detects VM and host failures and
replaces an unhealthy VM.

**Application health check** has three choices:

- **VM status only** is the default. The group checks only the VM and host status, and a VM is healthy
  when it reports ready. To check your application itself, choose **HTTP** or **TCP**.
- **HTTP**: the group calls an HTTP endpoint on each VM and replaces any that fail.
- **TCP**: the group opens a TCP connection to a port on each VM and replaces any that fail.

## Set up an HTTP or TCP check

Choose **HTTP** or **TCP**, then set the check. The defaults are a good place to start:

| Field                         | Default | Rule                      |
| ----------------------------- | ------- | ------------------------- |
| **Protocol** (HTTP only)      | HTTP    | **HTTP** or **HTTPS**     |
| **Port**                      | 80      | 1 to 65535                |
| **Path** (HTTP only)          | `/`     | Starts with `/`           |
| **Interval (seconds)**        | 30      | At least 15               |
| **Timeout (seconds)**         | 5       | From 1 up to the interval |
| **Unhealthy after (fails)**   | 3       | At least 1                |
| **Healthy after (successes)** | 2       | At least 1                |

The check goes to the VM's private IP. An HTTP check passes on any answer from 200 to 299, and an HTTPS
check accepts a self-signed certificate. A TCP check passes when it opens a connection within
the timeout. A VM must fail **Unhealthy after** checks in a row before it is replaced, and it is
cleared after **Healthy after** passes.

Then tell the group how long your app takes to start: **Under 30s**, **1 minute**, **3 minutes**, **5
minutes** (the default) or **Custom** in seconds. The group ignores health checks while a new VM is
starting.

## What happens to a VM that fails

The group builds a new VM from the source snapshot, so the new VM starts with only what the
snapshot holds. Keep data you need somewhere else. Because a failed check replaces the VM, point the check at a port and path that only fail when your application is
down. The default port 80 and path `/` are a starting point.

Checks run only while the group is **Running**.

## See the result

**Scaling Activity** records "Replaced an unhealthy VM" with the reason, such as a timeout, a refused
connection or an HTTP error, the time it first failed and the target. On **VMs & Monitoring**, the
removed VM is marked "Replaced after failing health checks", and the group's **Configuration** on
**Overview** names the check in force.

To see how scaling and replacement fit together, read [How auto scaling
works](/tir/tir-auto-scaling/concepts/how-auto-scaling-works/). To change capacity by usage, see [Scale
on usage](/tir/tir-auto-scaling/how-to/scale-on-usage/).