Is there an Turtl outage?
Turtl status: Systems Active
Last checked: 3 minutes ago
Get notified about any outages, downtime or incidents for Turtl and 1800+ other cloud vendors. Monitor 10 companies, for free.
Last checked: 3 minutes ago
Get notified about any outages, downtime or incidents for Turtl and 1800+ other cloud vendors. Monitor 10 companies, for free.
Outage and incident data over the last 30 days for Turtl.
Join OutLogger to be notified when any of your vendors or the components you use experience an outage. It's completely free and takes less than 2 minutes!
Sign Up NowOutlogger tracks the status of these components for Xero:
| Component | Status |
|---|---|
| Analytics reports | Active |
| Assets generation | Active |
| Editor | Active |
| Fastly London (LON) | Active |
| Filestack API | Active |
| Personalization | Active |
| Support web chat | Active |
| Viewer | Active |
View the latest incidents for Turtl and check for official updates:
Description: Our third-party provider has now resolved their issues. We have tested this in Turtl and confirm that all is back up and running.
Status: Resolved
Impact: Minor | Started At: Sept. 30, 2020, 4:10 p.m.
Description: Our third party provider has now resolved their issues. We have tested this in Turtl and confirm that all is back up and running
Status: Resolved
Impact: Minor | Started At: Sept. 28, 2020, 12:17 p.m.
Description: Our third party provider has now resolved their issues. We have tested this in Turtl and confirm that all is back up and running
Status: Resolved
Impact: Minor | Started At: Sept. 28, 2020, 12:17 p.m.
Description: \# Postmortem -- Incident 29th June 2020 \## Summary Over the last weekend, on 28th June 2020, we switched on the Workspaces feature for 25 of our customers. On Monday morning, at 9:18 BST, we were notified of an outage by automated alarms. The outage only lasted 2 minutes, but we continued observing intermittent degraded performance and short outages for the next several hours. There were 3 more short outages until 11:41 BST. During this time, some of the users experienced slow or failed requests to our servers. We were able to identify performance bottlenecks and address them in our codebase within 2 hours of the first outage. Unfortunately, we were not able to deploy that optimisation immediately because our code hosting provider, GitHub, was also experiencing an outage at that time. The first optimisation was deployed at 1:09pm BST and the second one at 6:47pm BST. We were closely monitoring the application performance during the next 24 hours. No similar degradations were detected by 2pm BST on 30th June, so we closed the incident. \## Details The new Workspaces feature allows users to see a list of all the docs owned by a single customer. For customers that have many docs, this list was causing performance issues, as it also performs several dynamic counts across the entire list. These aggregate database queries are performed in memory. Whenever too many of these slow queries were occurring simultaneously, the memory on our primary database server was exhausted, causing it to become unresponsive. Because several of these counts were not essential, we removed them temporarily. Another feature that comes with Workspaces is the home page that displays a list of recently edited docs by the current user. This feature proved to be another performance bottleneck due to the underlying database query. We were able resolve this particular issue by introducing a new database index. \## Further steps We will increase the amount of resources in our database cluster, especially memory. We will also introduce database query caching for certain resource-intensive cases and will also consider alternative ways to do dynamic counts across large lists of docs. \## Incident timeline \(BST\) \* 09:18 - first outage, degraded performance \(2 minutes\) \* 10:15 - second outage \(11 minutes\) \* 10:14 - GitHub outage started \* 11:28 - third outage \(2 minutes\) \* 11:34 - fourth outage \(7 minutes\) \* 12:38 - GitHub outage ended \* 13:09 - first optimisation deployed \* 18:47 - second optimisation deployed
Status: Postmortem
Impact: Major | Started At: June 29, 2020, 8:44 a.m.
Description: \# Postmortem -- Incident 29th June 2020 \## Summary Over the last weekend, on 28th June 2020, we switched on the Workspaces feature for 25 of our customers. On Monday morning, at 9:18 BST, we were notified of an outage by automated alarms. The outage only lasted 2 minutes, but we continued observing intermittent degraded performance and short outages for the next several hours. There were 3 more short outages until 11:41 BST. During this time, some of the users experienced slow or failed requests to our servers. We were able to identify performance bottlenecks and address them in our codebase within 2 hours of the first outage. Unfortunately, we were not able to deploy that optimisation immediately because our code hosting provider, GitHub, was also experiencing an outage at that time. The first optimisation was deployed at 1:09pm BST and the second one at 6:47pm BST. We were closely monitoring the application performance during the next 24 hours. No similar degradations were detected by 2pm BST on 30th June, so we closed the incident. \## Details The new Workspaces feature allows users to see a list of all the docs owned by a single customer. For customers that have many docs, this list was causing performance issues, as it also performs several dynamic counts across the entire list. These aggregate database queries are performed in memory. Whenever too many of these slow queries were occurring simultaneously, the memory on our primary database server was exhausted, causing it to become unresponsive. Because several of these counts were not essential, we removed them temporarily. Another feature that comes with Workspaces is the home page that displays a list of recently edited docs by the current user. This feature proved to be another performance bottleneck due to the underlying database query. We were able resolve this particular issue by introducing a new database index. \## Further steps We will increase the amount of resources in our database cluster, especially memory. We will also introduce database query caching for certain resource-intensive cases and will also consider alternative ways to do dynamic counts across large lists of docs. \## Incident timeline \(BST\) \* 09:18 - first outage, degraded performance \(2 minutes\) \* 10:15 - second outage \(11 minutes\) \* 10:14 - GitHub outage started \* 11:28 - third outage \(2 minutes\) \* 11:34 - fourth outage \(7 minutes\) \* 12:38 - GitHub outage ended \* 13:09 - first optimisation deployed \* 18:47 - second optimisation deployed
Status: Postmortem
Impact: Major | Started At: June 29, 2020, 8:44 a.m.
Join OutLogger to be notified when any of your vendors or the components you use experience an outage or down time. Join for free - no credit card required.
