Last updated Nov 14, 2022

App availability success rate

App availability is measured using app health check requests, which are HTTP GET requests sent from the Atlassian infrastructure to an app-defined endpoint. This metric is intended as a baseline for all metrics in the Cloud Fortified program.

Atlassian will make unauthenticated requests to the health check endpoint approximately every 60 seconds. The health check must return a successful HTTP response if the app is healthy, and must not return a successful HTTP response if the app is down.

From April 24, 2023, Cloud Fortified apps must meet a set of new requirements. This means that:

All app base URLs that receive customer traffic will be monitored, including the latest version of the app. the last patch version for each minor version with installations, and all regions for app versions that support data residency.
The 99.9% 28-day target SLO will be applied to each app base URL individually.
App health check URLs must be relative to the app's base URL.
A single health check path will be used along with all app base URLs.
Only the HTTP status code 200 OK will be accepted.
An HTTP response must be returned within 3 seconds.
HTTP redirections won't be followed.

Event definitions

Good event: an app health check request that returns an HTTP response with a 2xx Successful status code.

Bad event: an app health check request that returns an HTTP response with any other status code.

Target SLO

Cloud Fortified apps must maintain an app availability success rate of at least 99.9% over 28 days. This allows for approximately 40 minutes of downtime per month.

To provide early warning of potential future SLO breaches, we'll notify you if at least 1 app health check request has failed in the last 15 minutes.

Best practices

We would recommend that you create a dedicated health check endpoint for this purpose, but apps may use an existing URL that meets the above criteria. Your app may have such a resource, for example, for load balancer health-checking or provided by your app framework.

You may verify connectivity to any service dependencies, such as your persistent storage, from that endpoint, if you can reliably do so in under 3 seconds. The endpoint should typically not exercise end-to-end user experiences.

For apps backed by a server, it is not appropriate to use a static resource as the health check endpoint. Specifically, unless atlassian-connect.json is generated dynamically by your server, it shouldn't be used for this purpose. For apps consisting only of static resources, any of those resources can be used.