Rate this page:
The reliability requirements for Cloud Fortified apps are built around these principles:
Creating a reliable experience for customers
The Cloud Fortified program measures the reliability of apps using specific metrics – Service Level Indicators (SLIs). Each SLI has its target value – Service Level Objective (SLO).
Service Level Indicator (SLI) is the measurement you use to track your app's capabilities (such as uptime or response time).
Service Level Objective (SLO) is the target declared about a specific SLI (for example, 99.95% uptime). In the Cloud Fortified program, SLOs are measured over 28 days.
Example:
SLI (metric) | SLO (target value) |
---|---|
App availability success rate | 99.9% |
A Cloud Fortified app is considered reliable when it consistently meets the SLO of each SLI.
Detecting incidents before customers
The Cloud Fortified program reduces the Mean Time To Detect (MTTD) by sending alerts when a metric is breached. It drives patterns and behaviors than enable partners to detect issues by monitoring rather than relying on customers to report issues.
Synthetic tests are automated tests that simulate real user interactions to validate core app capabilities and experiences. They are usually implemented with emulated web browsers or recorded web requests.
In this context, we suggest you implement automated tests that simulate users interacting with your app through Jira or Confluence and run them regularly against your Developer First Rollout instance.
Synthetic tests let you spot cases where product changes quickly degrade your app's core capabilities.
To implement synthetic tests:
The Metrics publish API has been deprecated and will be removed after April 24, 2023.
PUT - /rest/atlassian-connect/latest/addons-metrics/${addon_key}/publish
This API is used by Cloud Fortified apps to:
These metrics were removed from the program on October 24, 2022.
Header | Description |
---|---|
Authorization | JWT ${token} See Connect JWT documentation |
Content-Type | application/json |
Name | Description |
---|---|
appKey *required (Path parameter) | App Key |
body *required (Body) | Array<AddonMetrics> List of metrics data to publish AddonMetrics: metricsType *required enum: IFRAME or SYNTHETIC Metrics type which will be used to construct metrics name. (eg. metrics.external.connect.synthetic.successful) moduleType string Module type of the metric. Only applicable to IFRAME metrics. This value must be a valid Connect module type for the product, a valid key in the "modules" field in the app descriptor, e.g. "adminPages" .durationInMillis long Duration of the successful checks that will be used for Capability metrics. Metrics with failed status will not publish this latency data. status *required enum: SUCCESS or FAIL Indicates if the check was successful. This will be used when calculating reliability metrics. |
Code | Description |
---|---|
200 Success | Successfully published metrics |
403 Forbidden | Request not allowed for appKey Wrong authentication signature Request is only allowed from the app server with a valid installation |
408 Bad Request | Latency should not be a negative value Metrics type not supported Unknown module type |
To enable Atlassian to obtain a baseline measurement of whether a Connect app is up, you must provide the URL of a health check resource for your app.
See App availability success rate for detailed requirements for health checks.
Information |
Type of information |
Why do we need it |
---|---|---|
Your app's scalability characteristics |
|
We want to make sure you have considered your app's scalability characteristics and have validated them to a reasonable degree. |
Testing against Developer First Rollout instances |
Sign up for a Developer First Rollout instance to validate your app. See the sign up form: Jira and Confluence. Describe any pre- or post-deployment testing you do against the Developer First Rollout instance. |
We expect Cloud Fortified apps to use Developer First Rollout instances to detect unexpected behavior when product changes are rolled out as early as possible. |
Your service recovery plan |
Define the recovery plan for your app.
|
We want to ensure you have developed a straightforward approach for rolling out fixes to production and managing data restores if necessary. |
Your existing incident management process |
Describe your incident management process:
|
We're looking to understand your approach to incident management so we can collaborate on improving the incident response. |
Once we have granted you access, validate the access and familiarize yourself with the developer console (for Connect apps).
Confirm the metrics on the developer console match your expectations. Please contact us if there is any unexpected behavior (for example, suspicious or missing data).
Make sure you receive email notifications when SLIs breach their SLOs.
Act on deprecation notices within the deprecation period.
Rate this page: