Tiers help engineering teams define and understand how critical software components are to their software architecture and organization. The lower the tier number, the more critical the component.
Tiers also have an associated quality standard, called a service level agreement (SLA).
SLAs are defined on a per-organization basis (because different organizations have different standards) but can include things like component availability and reliability targets, as well as required response times for restoring a component back to full functionality.
Learn how Atlassian uses tiers and SLAs for operational readiness
Tier 1 components are essential for an organization’s software architecture to function. If they fail, they could seriously impact the organization and its customers. These could be things like login services, permission services, or API gateways.
Tier 2 components are important to the organization’s software architecture and if they fail, could degrade the customer experience. These could be things like search services, or order-fulfillment services.
Tier 3 components, if they fail, have minor or difficult-to-notice impacts on an organization and its customers. These could be things like icon services, or recommendation services.
Tier 4 components have no significant effect on the customer experience and do not significantly affect the organization. These could be things like experimental features, or analytical services.
When a component is created, it’s set to the least critical tier of 4. To accurately reflect how critical that component is to your organization, update its tier as soon as possible.
Go to a component's Overview page.
Below the component’s name, select the Tier dropdown and choose a tier that’s appropriate to your organization’s standards. The lower the number, the more critical the component.
Rate this page: