Last updated Jun 15, 2022

Rate this page:

Atlassian app incident severity levels for developers and partners

At Atlassian, we define an incident as an event that disrupts or reduces the quality of a service that requires an emergency response. We consider an app incident to be any instance where there is an existing or impending negative impact on our app and integration partners.

How we respond to incidents centres around our values. We aim to handle incidents in a way that aligns with the interests of our developers, partners, and customers. Our process strives to be consistent, repeatable, and efficient.

To increase transparency, we’re sharing our approach to defining severity levels of incidents related to apps. This is a key part of our journey to improve incident management between Atlassian and our developers and partners.

Reporting an incident

Currently, you can report incidents through the following channels:

Note: We’re working on a new, dedicated space for creating app-related incidents. The estimated launch date is July 2022.

Incident severity definitions

Severity definitions help us identify an adequate response to an incident. There are three severity levels: SEV 1 - CRITICAL, SEV 2 - MAJOR, and SEV 3 - MINOR.

Incident types

We’ve created an internal framework that helps us prioritize incidents based on the type of information available during the event. Our primary point of reference is the number of users or apps affected by the event. If those numbers aren’t available, we use capability-based definitions.

Incidents impacting end-users or partners

The app incident severity level is defined based on the number of affected end-users or apps.

Example: An outage of an API used for retrieving properties of an issue entity.

Level1,000-100,000 or 3-10 apps affected100,001-5,000,000 users or 11-100 appsMore than 5,000,000 users or more than 100 apps
MajorSEV 3SEV 2SEV 1
MinorSEV 3SEV 3SEV 2

Capability-based incident severity definitions

If we can’t assess the impact based on the number of affected end-users or apps, we refer to the capability tiers.

In the capability-based framework, we distinguish two categories of incidents:

  • An outage — for example, when a Forge app deployment doesn’t work.
  • Degradation of a capability — for example, when an app slows down.
Capability outage
Capability tiersLess than 2 hours2-5 hoursMore than 5 hours
Capability degradation
Capability tiersLess than 2 hours2-5 hoursMore than 5 hours

For a full list of capabilities and their associated tiers, see "Atlassian ecosystem and Marketplace capabilities" below.

When it comes to incidents, we want to be as responsive as possible. We escalate incidents according to the number of reports we receive from Partners through our service desks and community posts.

Incidents are escalated according to this scale:

Number of Partner reportsEscalation
More than 2SEV 3
More than 5SEV 2
More than 15SEV 1

Atlassian ecosystem and Marketplace capabilities

Ecosystem capabilities

App code execution: underlying execution environment for running third party code.C1
App network egress: permissions and enforcement of app egress to external URLs.C1
App UI: rendering and integration of third party app user interfaces in products.C1
Content delivery (CDN): static asset delivery of hosted app assets and common libraries (ac.js, Forge bridge).C1
End-user consent: prompt for consent of specific permissions for an app.C1
Extension discovery: ability for products to fetch app modules for use in product extension points. C1
Function invocation: backend functionality for Atlassian-hosted apps. Powers app modules where a function is specified.C1
Hosted storage: Atlassian-hosted storage for hosted and remote compute.C1
Webtriggers: external endpoint that invokes third party compute. Commonly used as webhooks for data ingestion.C1
App deployment: ability for a third-party developer to roll out changes in their app.C2
App distribution: ability for developers to publish and distribute their app via Marketplace or direct distribution.C2
App installation: ability for admins and developers to install apps in a product.C2
App lifecycle events: events that are triggered at different stages in the lifecycle of an app installation (for example, installation or permission upgrade).C2
App monitoring: web UI for monitoring app metrics with the developer console.C2
Async events: queue service that enables hosted compute to split out workloads into multiple asynchronous tasks.C2
Command-line interface: ability for a developer to create, tunnel, deploy, and install apps at the command line.C2
External API authentication: credentials and auth flow management for external APIs.C2
Product events: product event subscriptions that trigger third-party compute.C2
Scheduled triggers: ability for developers to schedule compute on a time schedule. Similar to cron jobs.C2
App logging: web UI for viewing app logs with the developer console.C3
Developer documentation: single source of truth for Atlassian product and platform developer documentation.C3
Manage apps: web UI for managing apps with the developer console.C3

Marketplace capabilities

Download appC1
Install apps (cloud Only)C1
Search apps C1
View app listingC1
View home pageC1
Aggregation reportsC2
Churn reportsC2
Cloud conversion reportsC2
Cloud renewals reportsC2
Create accountC2
Fetch feedback reportsC2
Fetch licenses reportsC2
Fetch transactions reportsC2
Publish app versionC2
Manage contactC2
Publish new appC2
Set app migration infoC2
Set app pricingC2
Update accountC2
Update app migration infoC2
Update app pricingC2
Update app versionC2
Request appsC3
Request managementC3

Rate this page: