Is Confluence Down?

### Summary On Jan 08, 2026 between 14:54 UTC and 16:30 UTC, Atlassian customers using Confluence Cloud product\(s\) experienced degraded service with view/edit page experiences. The event was triggered by database overload due to an unexpected large burst of traffic. The database overload was the result of a configuration change, which led to a sudden spike in database connections, which impacted a subset of customers in a single partition in the us-east region. The incident was detected within 1 minute by by automated monitoring systems and mitigated by reducing the number of web server hosts connecting to the database layer, which put Atlassian systems into a known good state. The total time to resolution was about 1 hour and 26 minutes. ### **IMPACT** The overall impact was between Jan 08, 2026, 14:54 UTC and 16:30 UTC on Confluence Cloud products. The incident caused service disruption to customers in a single partition in the us-east region impacting the ability to view and edit pages. We observed partition-wide database saturation due to an unexpected large burst of traffic. Confluence Cloud components impacted during this window were: Login, View / Edit Page, Publish Page, Add Page, Comment. ### **ROOT CAUSE** A change was introduced that caused cross-region traffic routing for customers instead of routing to the same region. Some caches processing customer data were stale, which heavily loaded the databases and caused them to restart. As a result, the users of the product above could not login, view or edit pages, and the users received HTTP 500 and 504 errors. ### **REMEDIAL ACTIONS PLAN & NEXT STEPS** We know that outages impact your productivity. While we have a number of testing and preventative processes in place, this specific issue wasn’t identified due to a specific set of factors which resulted in this condition. We are prioritizing the following improvement actions to help avoid repeating this type of incident: * Fix the routing issue that resulted in cross-regional traffic * Decrease maximum number of connections per database instance, to allow for sufficient memory capacity to handle a surge in connections Furthermore, we deploy our changes progressively \(by cloud region\) to avoid broad impact but in this case, the impact was larger than desired. To minimize the impact of breaking changes to our environments, we will implement additional preventative measures such as enabling automatic vertical scaling when database clusters are running low on memory. We apologize to customers whose services were impacted during this incident; we are taking steps to help improve the platform’s performance and availability. Thanks, Atlassian Customer Support

### Summary On **December 27, 2025**, between **02:48 UTC and 05:20 UTC**, some Atlassian cloud customers experienced failures in sending and receiving emails and mobile notifications. Core Jira and Confluence functionality remained available. The issue was triggered when **TLS certificates used by Atlassian’s monitoring infrastructure expired**, causing parts of our metrics pipeline to stop accepting traffic. Services responsible for email and mobile notifications had a critical path dependency on monitoring path leading to service disruptions. All impacted services were fully restored by **05:20 UTC**, around **2.5 hours** after customer impact began. ### IMPACT During the impact window, customers experienced: * **Outbound product email failures** \(notifications and other product emails did not send\). * **Identity and account flow failures** where emails were required \(e.g. sign‑ups, password resets, one‑time‑password / step‑up challenges\). * **Jira and Confluence mobile push notifications** * **Customer site activations and some admin policy changes** failing and requiring later reprocessing. ### ROOT CAUSE The incident was caused by: 1. **Expired TLS certificates** on domains used by our monitoring and metrics infrastructure caused by **misconfigured DNS authorization record** which prevented automatic renewal. 2. **Tight coupling of services to metrics publishing**, which caused them to fail when monitoring endpoints became unavailable, instead of degrading gracefully. ### REMEDIAL ACTIONS PLAN & NEXT STEPS We recognize that outages like this have a direct impact on customers’ ability to receive important notifications, complete account tasks, and operate their sites. We are prioritizing the following actions to improve our existing testing, monitoring and certificate management processes: * **Hardening monitoring and certificate infrastructure** * We are refining DNS and certificate configuration across our monitoring domains and strengthening proactive checks to detect and address failed renewals and certificate issues well before expiry. * We are also improving alerting on our monitoring and metrics pipeline. * **Decoupling monitoring from critical customer flows** We are updating services such as outbound email, identity, mobile push, provisioning, and admin policy changes so they no longer depend on metrics publishing to operate. If monitoring becomes unavailable, these services will continue to run and degrade gracefully by dropping or buffering metrics instead of failing customer operations. We apologize to customers impacted during this incident. We are implementing the improvements above to help ensure that similar issues are avoided. Thanks, Atlassian Customer Support

On December 15th, 2025, Admin Hub, Atlassian Analytics, Confluence Cloud, Ecosystem, Focus, Jira, Jira Product Discovery, Jira Service Management, and Rovo users in the prod-us-east region may have experienced performance degradations and errors on the web page and mobile apps. The issue has now been resolved, and the service is operating normally for all affected customers.

The rollback required to resolve this issue is now completed, and we have verified across the impacted products that App installation behaviour is now working as expected. We apologize for any inconvenience this may have caused.

### Summary On November 21, 2025, between 13:44 and 15:16 UTC, Trello customers were intermittently unable to view and update data on their boards. Customers also may have experienced issues authenticating with Atlassian products, and creating new GitHub and Slack integrations. The event was triggered by a bug encountered in the software running our edge proxy fleet, which proxies customer traffic to Atlassian cloud services. The changes included the migration of our edge proxy fleet to hosts running an ARM CPU architecture, rather than the AMD64 CPU architecture they had previously been running, which impacted US East customers. The incident was detected within 1 minute by our automated monitoring systems, and mitigated by a scale up of of fleet size, which put Atlassian systems into a known good state. This was followed by a global migration of edge proxy fleet hosts back to AMD64 CPU architecture the following day. ### **IMPACT** During the impact window, US East customers intermittently could not view or update data in Trello. The same underlying issue also impacted our Identity services and integrations with GitHub and Slack, meaning some customers had trouble signing in to Atlassian products or creating new integrations. At the incident’s peak, the incident impacted up to: * 52% of new Trello network connections. * 9% of new GitHub and Slack integrations. * 8% of new Identity network connections. ### **ROOT CAUSE** The issue was caused by a change to CPU architecture from AMD64 to ARM on our edge proxy fleet. This led to a bug that caused these instances to stall under high load, and refuse up to 52% of new connections. As a result, some customers of the products above could not make new connections to Atlassian services, and customers received CloudFront 504 gateway timeout error responses. ### **REMEDIAL ACTIONS PLAN & NEXT STEPS** We know that outages impact your productivity. While we deploy our changes progressively by cloud region to avoid broad impact, on this occasion, our pre-change load testing had not accurately reflected production loads. As part of our response to this incident, and to help prevent recurrence, we rolled back all edge proxy fleets from ARM to AMD64 CPU architecture globally. To minimise the impact of breaking changes to our environments, we plan to implement additional preventative measures such as: * Adding improved load tests into edge proxy fleet deployment pipelines to catch load-related bugs before deployment to production. * Adding alerts to our edge proxy fleet to catch rises in TCP connect times before customer impact. We apologize to customers whose services were impacted during this incident; we are taking steps to help improve the platform’s performance and availability. Thanks, Atlassian Customer Support