Exoprise CloudReady® Help
Search:     Advanced search

CloudReady Status

Article ID: 91
Last updated: 27 Jul, 2017

Exoprise continuously monitors the operations of its service — using CloudReady sensors itself (kind of recursive) and other services. If there are any interruptions in service, planned or unplanned, a note will be posted here.

Core Servers

Public Sites

Alarms

IP Geo Service

IP Maps Service

Service Communications API

Good

Good

Good

Good

Good Good

July 27, 2017 - 10:13 AM ET

  • The availability zone within one of our cloud hosting providers, Amazon, has recovered. Mail autoresponders and core servers are recovering or fully recovered.

July 27, 2017 - 09:50 AM ET

  • We investigating a number of failures with one of our cloud hosting provider, Amazon. Possible outages related to our autoresponders and occasional slowness, failures in core CloudReady Servers. We will update this page within one hour when more information is available.

June 13, 2017 - 10:45 AM ET

  • We fixed a problem with CloudReady servers and the Office 365 service communications API. During deployment of a service communications API update, the servers experienced increased load which caused some of the servers to stop responding and slowed processing. While we were investigating the issue we had to temporarily stop and restart the servers. No data should have been lost from the Private Sites as they are designed to cache and replay data during an outage. We apologize for any inconvenience this may have caused and we will investigate ways to prevent this brief outage and slowdown in the future.

June 13, 2017 - 10:19 AM ET

  • Some users may be experiencing intermittent slow login and dashboard refresh problems with CloudReady. Engineers are investigating the issue and implementing a fix. A new status entry will be updated when the situation is resolved.

June 12, 2017 - 6:30 PM ET

  • We are experiencing difficulties accessing Microsoft's Service Communications API and working with Microsoft to investigate the issue. We hope to have it resolved this morning and will post a resolution when more information is known.

June 2nd,  2017 -  4:00 PM ET

  • The issue with incorrect GeoIP lookup for sites has been corrected. Private sites should be correctly located on the maps, provided their IP can be correctly geo-located as before.

June 1st,  2017 -  4:00 PM ET

  • CloudReady is incorrectly reporting some GeoIP data for sensors and, in turn, the sites may appear in the wrong locations on the maps. We are working on resolving the situation and hope to have it fixed soon. Once the issue is resolved, the site maps should update with the proper Geo location.

March 14th, 2017 - 6:00 PM ET

  • Microsoft's Service Communications API has recovered.

March 14th, 2017 - 1:00 PM ET

  • Microsoft's Service Communications API is experiencing a wide-scale outage and is not currently accessible. We will update this page when the API is available again.

March 6th, 2017 - 9:17 AM EST

  • The Sydney Public Sites are back online.

March 6th, 2017 - 9:10 AM EST

  • The Sydney Public Sites are currently being re-balanced and expanded. The Sydney Public Sites may be offline for a period of up to 20 minutes.

August 30th, 2016 - 12:00 PM

  • Microsoft's Service Communications API has recovered and improved over the past few weeks. We are updating this status page to reflect a more stable Service Communications API.

August 9th-10th, 2016 - 7:56 PM

  • Microsoft's Service Communications API continues to have issues as it has, periodically, since the beginning of August. The issue has been reported to Microsoft. Periodically, the Service Communications API is unavailable, timing out and returning errors. While we continue to investigate mitigation strategies and notify Microsoft of the problem our own CloudReady monitoring service is completely unaffected.

June 8th, 2016 - 7:56 PM

  • Microsoft's Service Communications API has recovered. The Service Communications API was unexpectedly returning a deauth code (401) when it shouldn't have been. This is contrary to the specification and fixed for the moment. We will be investigating different retry strategies for when an unexpected (and not to specification) deauth is returned.

June 8th, 2016 - 6:00 PM

  • Microsoft's Service Communications API is experiencing OAuth deauthorization failures. We are investigating the issue.

June 5th, 2016 - 6:35 AM

  • We have successfully recovered all Public Site instances in the Sydney region. In some cases the Public Site Virtual Machines needed to be restarted so they were moved to new availability zones within the Amazon Web Services datacenter in Sydney. Public Sensors in the Sydney should now be fully recovered.

June 5th, 2016 - 5:30 AM

  • Some of the Exoprise CloudReady Public Sites in Sydney are suffering connectivity errors and failures. The sites are being affected by widespread Amazon outages in the Sydney data centers. We are working to recover the sites as quickly as possible.

January 21st, 2016

  • Microsoft's Service Communications API has recovered the integrated service views are available again.

January 20th, 2016

  • Microsoft's Service Communications API is experiencing sporadic outages today. We have notified Microsoft of the issue and are awaiting a fix or an updated.

Prev   Next
CloudReady Status     Getting Started