Last updated Feb 23, 2023

App incident severity levels

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

Our response to incidents centers around our values. We aim to handle incidents in a way that aligns with the interests of our developers, partners, and customers. We strive to build a process that is 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.

For a general introduction to Atlassian's approach to incident management and severity levels, see Incident Management and Understanding incident severity levels.

Reporting an incident

To report an incident, use these channels:

How we determine app incident severity

Severity definitions help us identify an adequate response to an incident. We’ve created an internal framework that helps us determine the severity of incidents based on the type of information available during the event.

Our primary point of reference is the number of end-users or apps affected by the event. When those numbers aren’t available, we use capability-based definitions.

Our incident framework includes these severity levels: SEV 1 - CRITICAL, SEV 2 - MAJOR, and SEV 3 - MINOR.

Determining severity based on the number of affected end-users or apps

When we know the number of end-users or apps affected by an incident, such as an API outage, we use that data to determine severity.

Level1,000-100,000 affected users or 3-10 affected apps100,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

Determining severity based on affected capabilities

When we can’t assess the severity of an incident based on the number of affected end-users or apps, we use a capability-based framework.

Each capability in our development ecosystem and the Atlassian Marketplace belongs to one of three tiers — C1, C2, or C3. The tiers rank capabilities by their relative criticality, where C1 is the most critical tier and C3 is the least. For example, app deployment is a C1 capability while app logging is C3. (For a full list of capabilities and their associated tiers, see the Ecosystem and Marketplace capabilities section.)

The capability framework also distinguishes two types 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.

We use the following tables to determine severity based on the type of incident, the tier of the affected capability, and the incident's duration.

Capability outage
Capability tierLess than 2 hours2-5 hoursMore than 5 hours
Capability degradation
Capability tierLess than 2 hours2-5 hoursMore than 5 hours

How we escalate incidents based on partner reports

When it comes to incidents, we want to be as responsive as possible. We escalate incidents according to the number of reports gathered from partners through 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

How we respond to incidents

The following details are provided for informational purposes so that Marketplace Partners and the developer community have more insight into how we respond to incidents.

Atlassian aims for the following, when possible:

  • Major incidents (Sev 1 and Sev 2): Incident response teams start an investigation within 15 minutes of being paged and publish an initial status update within 1 hour of the incident start time. We define the incident start time as the point when the incident started impacting customers or partners. Atlassian strives to resolve Major incidents as quickly as possible.

  • Minor incidents (Sev 3): Teams treat these incidents as high priority during local business hours and within existing release schedules.

For status on incidents that affect APIs, the Marketplace, and developers in general, visit For more detail on critical incidents, visit the public critical incident tickets page.

To drive continuous improvements in our processes, Atlassian actively monitors and analyzes a variety of metrics related to incidents.

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 the consent of specific permissions for an app.C1
Extension discovery: the ability for products to fetch app modules for use in product eension 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 resources.C1
Webtriggers: external endpoint that invokes third-party compute resources. Commonly used as webhooks for data ingestion.C1
App deployment: the ability for a third-party developer to roll out changes in their app.C2
App distribution: the ability for developers to publish and distribute their app via Marketplace or direct distribution.C2
App installation: the ability for admins and developers to install apps in a product.C2
App lifecycle events: events that are triggered at different life stages of an app installation. (installation, permission upgrade).C2
App monitoring: web UI for monitoring app metrics via the developer console.C2
Async events: queue service that enables hosted compute resources to split out workloads into multiple asynchronous tasks.C2
Command-line interface: the 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 resources.C2
Scheduled triggers: the ability for developers to schedule compute resources. Similar to cron jobs.C2
App logging: web UI for viewing app logs via the developer console.C3
Developer documentation: a single source of truth for Atlassian product and platform developer documentation.C3
Manage apps: web UI for managing apps via the developer console.C3
Identify App Constraints: Ability for Atlassian screens (e.g. Connected apps in Admin hub) to discover what apps are impacted by app access rules within a given site.C2
Data Security Policy Events: Ability for apps to receive events when an app's access to certain data has been blocked by an administrative policy.C2
Connect Data Residency: Ability for admins and app developers to migrate their connect app data to a desired region.C2

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: