Skip to end of metadata
Go to start of metadata

Note, this page only applies to Cloud Apps and does not apply to Server or Data Center Apps.

We are committed to providing reliable and resilient infrastructure for our Cloud Apps, with the following pillars:

☄️ Performance

We monitor the performance of our Cloud Apps using a number of metrics:

  • CPU Load
  • Response Time
  • Error Rates

Monitoring these metrics means we can maintain the right performance levels for all customers.

We use CloudFront to provide static resources to users from the nearest region.

We believe transparency is important to building trust with our customers and as such we provide public metrics including Average Response Time (in ms) and System Load.

View our StatusPage to see the system metrics and uptime reports.

☀️ Reliability

Reliability describes the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions.

We aim for a uptime of 99.99%. The Atlassian uptime target is 99.95%. Note we do not have an official SLA and this is a target.

We host the Apps on highly available infrastructure and have disaster recovery procedures in place to ensure that you can rely on our Apps.

❇️ High Availability

Each App is hosted on a minimum of 2 Application Containers, spread equally across the Availability Zones.

Application Containers are scaled automatically based on End User Demand, ensuring that capacity is managed dynamically.

This ensures that the response times are kept within a known range. 

👑 Resilience

Our hosting infrastructure was built from the ground-up to handle outages at different levels:

  1. DNS and CloudFront* are hosted at the Global-level and is resilient to problems at a Region-level.
  2. Load Balancers are hosted at the Region-level and are resilient to problems at the Zone-level.
  3. Apps are hosted in 2 Zones and are resilient to problems in between 1 and 2 Zones.
  4. App Databases are hosted across 3 Zones and are resilient to problems in 2 Zones.

*We use CloudFront to provide a level of protection from distributed attacks by only allowing connections via CloudFront.

Using this infrastructure our hosting is resilient to a failure of between 1 and 2 Zones.

🌩️ Disaster Recovery

In the case that a major disaster happens involving our cloud provider or infrastructure, we will expedite the recovery of our Apps in a reasonable timeframe.

We store encrypted backups that can be deployed to new infrastructure in a different region or cloud provider in the event of a serious disaster which affects multiple AZ's or an entire region of our Cloud provider being inoperable.

🔑 Security

Security describes the steps we take to protect information & systems. Confidentiality, privileges and integrity of data are included.

Our Cloud applications are designed to allow application data to be accessible only with the correct credentials, ie. one customer cannot access another customer’s data.

We have completed the Security Self-Assessment with Atlassian and will inform both Atlassian and End-users if a breach is detected.

🛡️ Least Privilege

We operate on a policy of least privilege and this is applied to staff and services similarly:

  • Each Cloud App can only access it's own resources and cannot access other infrastructure or databases. ie. Sandboxed
  • Staff are given least-privilege access based on RBAC (role-based access control).
  • A QA and approval process is undertaken with each release.

🚥 Traceability

We monitor, alert, and audit actions and changes to our environment in real time.

Application, Access Logs and other Metrics are shared automatically with alerting systems which alert security when unauthorized access occurs.

💾 Data Storage/Transmission

Any data that we store is encrypted both at-rest and in transit:

  • Each database is encrypted at-rest using a private key using industry-standard AES encryption.
  • All traffic is encrypted with industry-standard HTTPS TLS using a modern cipher suite.

Where possible, all Customer-specific App Data is stored on the Jira/Confluence/Trello etc. system itself and is not stored elsewhere.

The main exceptions to this rule are the Atlassian Connect Access Tokens, which are required to be stored by the App, and the Section Approval feature of Approvals for Confluence Cloud.

We will never share any customer data outside of Automation Consultants Limited.

🔭 Transparency

Our official channel for reporting on the status of our Cloud Apps is our StatusPage.

Please subscribe to updates for the Cloud Apps your company uses to stay up to date!


  • No labels