The Endpoint to Be Used for Testing or Monitoring Basic Connectivity to Okta
Last Updated:
Overview
Okta customers or third-party products they use may need to monitor an Okta tenant for basic connectivity/reachability.
Almost all Okta endpoints are rate-limited and incur varying performance impacts when called, including the top-level URL (for example, https://domain.okta.com), making it difficult to choose the best endpoint to use when monitoring or testing connectivity to an Okta tenant.
Applies To
- Rate Limits
- Reachability/Connectivity Monitoring tests/probes
- ZScaler ZDX
- Okta Classic Engine
- Okta Identity Engine (OIE)
Cause
Some third-party products include connectivity monitoring that regularly probes an endpoint to establish that it is reachable.
An example of this is the Zscaler VPN client component called ZDX, which is installed on employee workstations and supports a service monitoring feature whereby the software can identify loss of connectivity to important websites and provide diagnostic feedback. When configured with a default polling interval of 5 minutes and installed on thousands of client machines, it can easily saturate default rate limits on many Okta endpoints.
Solution
Okta provides a lightweight, performant, public reachability check endpoint to establish basic connectivity to our infrastructure edge without implying anything about the underlying service health and the associated performance hit that would entail.
- The endpoint is named
/ping.- For example:
https://domain.okta.com/ping
- For example:
- The
/pingendpoint will respond to a GET request with an HTTP response of 200 and an empty response body. - The
/pingendpoint is only supported for HTTPS and standard Okta domains; that is, custom URLs are not supported. - The
/pingendpoint is available for both production and preview tenants.
