Working with health checks

      Last updated August 13, 2019

    Health checks monitor the status of your hosts. Fastly performs health checks on your origin server based on the Check frequency setting you select in the Create a new health check page. The Check frequency setting you select specifies approximately how many requests per minute Fastly POPs are checked to see if they pass. There is roughly one health check per Fastly POP per period. Any checks that pass will be reported as "healthy."

    Creating a health check

    1. Log in to the Fastly web interface and click the Configure link.
    2. From the service menu, select the appropriate service.
    3. Click the Edit configuration button and then select Clone active. The Domains page appears.
    4. Click the Origins link. The Origins page appears.

      the Origins page

    5. Click the Create health check button. The Create a health check page appears.

      Create a health check

    6. Fill out the Create a health check fields as follows:
      • In the Name field, type a human-readable identifier for the health check (e.g., West Coast Origin Check).
      • From the Request menu, select an HTTP verb. In the Request field, type the path to visit when performing the check. Use a unique path. For example, use /website-healthcheck.txt, not / or /healthcheck.
      • In the Host header field, type the HTTP host header to set when making the request (e.g.,
      • From the Expected response menu, select the HTTP status code the origin servers must respond with for the check to pass (usually 200 OK).
      • In the Check frequency section, select a setting to control how often the health check is performed.
        • Low: One request every minute from each datacenter, where "healthy" means 1 out of 2 must pass.
        • Medium: One request every 15 seconds from each datacenter, where "healthy" means 3 out of 5 must pass.
        • High: One request every 2 seconds from each datacenter, where "healthy" means 7 out of 10 must pass.
        • Custom: A custom frequency you specify.
      • In the Threshold & Window fields, type the number of successes per total number health checks. For example, specifying 3/5 means 3 out of 5 checks must pass to be reported as healthy.
      • In the Initial field, type the number of requests to assume as passing on deploy. For example, if the Threshold & Window field is set to 3/5 and the Initial field is set to 1, a backend would be marked as “unhealthy” until it passed two more health checks to reach the required minimum.
      • In the Interval & Timeout (ms) fields, type times. Interval represents the period of time for the requests to run. Timeout represents the wait time until request is considered failed. Both times are specified in milliseconds.
    7. Click the Create button.

    Your new health check now appears in the list of checks.

    Assigning a health check

    Health checks do nothing on their own, but they can be added as a special parameter to an origin server in your configuration.

    1. Edit one of your existing origin servers by clicking the origin server's name. The Edit this host page appears.
    2. From the Health checks menu, select the health check you just created.
    3. Click Update.

    Fastly will now use the health check to monitor the selected origin server.


    Fastly will periodically check your origin server based on the options chosen. Pay special attention to the HTTP host header. A common mistake is setting the wrong host. If the origin server does not receive a host it expects, it may issue a 301 or 302 redirect causing the health check to fail. Also, Varnish requires the origin server receiving the health check requests to close the connection for each request. If the origin server does not close the connection, health checks will time out and fail.

    If an origin server is marked unhealthy due to health checks, Fastly will stop attempting to send requests to it. Once all of your origin servers are marked unhealthy, Fastly will return a 503 error (service unavailable) to the client unless you tell it otherwise. You can configure Fastly to attempt to serve stale content instead until your origin servers become available again.

    Back to Top