How Health Check Works

While the service-provider is enabled and has at least one capability enabled, a health-check event will be sent on a 5 minute interval. The health-check handler must respond in a timely fashion with a response message that has a HTTP 200 code and has the required JSON-content body.

A health-check failure one of these scenarios:

• Failure to respond within 10 seconds
• The HTTP response does not have a HTTP 200 status code.
• The HTTP content-type is not application/json.
• The HTTP content body is not the correct JSON object. See below for the JSON object shape.

The guide Implementing Health Check Handler has details on how to implement a successful health-check handler.

While the service-provider is enabled and has at least one capability enabled, a health-check failure will automatically move the service-provider to the pending state. When in the pending state, no webhook events will be sent to the service provider.

The pending state is different from the enabled or disabled states. After entering the pending state, health-check events will initially be sent on the same 5 minute interval for 2 more health-check failures (for a total of 3 sucessive failures). After the third health-check failure, the interval will be increased to 15 minutes. Health-checks will continue to be sent every 15 minutes indefinitely until the service-provider responds successfully to a health-check or is manually disabled or re-enabled in Production Administrator.

If the service-provider responds successfully to a health-check while in the pending state, it will automatically be changed back to the enabled state. Once returned to the enabled state, webhook events will again be sent to the service-provider.