针对4月初发生的断线事件，atlassian上周发布事后说明，指受影响的客户来到775家。
这事后报告说明断线事件不是出于网络攻击或被黑，而出于维护团队沟通及系统设计问题。事由是jira service management及jira software共享的“insight–asset management”独立app去年集成到jira service management中，因而必须删掉旧版独立app。但在执行时发生2项错误。一是请求删除app的团队给成了删除整个云计算网站的site id，而非该app的id，但atlassian标准的同侪审查（peer-review）并未检查到给出的site id。第二项错误是，删除网站或app的api并未能在接到site id（或app id）时发出警告并确认，而径自删除了网站。
种种乌龙造成的结果是，在世界协调时间（utc）4月5日早上7:38到8:01分775家客户的883个网站立即被删除，占其20多万客户的0.04%。2周前atlassian说被删除的网站为将近400个。
atlassian表示，事件发生时他们不是茫然无知，而是一开始就知道有哪些网站受影响。他们也知道第一要务是和网站负责人取得联系，不幸一些客户的联系资料遭到删除，这使得atlassian无法立即联系上客户，客户也无法通过支持工单通报。
整个断线历时14天，在抢修后第一批客户于4月8日回复上线。atlassian于4月18日说明所有受影响的客户均已恢复服务。该公司强调没有一家客户损失的资料超过5分钟，在回复服务期间，99.6%的云计算服务客户运行均没有任何中断。
为了防范事件重演，atlassian也修正了管理作业。第一是所有系统将禁止全网站删除，或采用各种防护措施，包括阶段性部署，以及回复计划。未来全球各站点都会导入“软删除”（soft delete），避免删除客户资料及metadata。
其次他们会扩大实施灾难恢复（disaster recovery，dr），以便在多站点、多产品删除事件发生时自动启动回复，加速回复时间目标（recovery time objective，rto）。atlassian也将改进大规模事件发生的sop（standard operating procedure）并且强化多团队协同的人员训练及工具。最后他们也将创建多渠道通报，加速事件确认及创建客户联系，并期盼在1小时内发布公开说明。