Feed available - Subscribe to our feed to stay up to date on upcoming maintenance and incidents. Kony Cloud status
Current status and incident report
February 15, 2016 (postponed until February 29th)
Maintenance window: February 15, 2016 00:01 UTC to February 15, 2016 04:00 UTC Impacted Cloud services:Management services (Release Notes - to be updated for 4.0)
Major release 4.0 upgrade
Impact Level : minor
No significant downtime is expected. The scheduled maintenance is designed for minimal disruption of service availability; however, it is possible for your service(s) to be unavailable for a short period of time during the maintenance window.
API and Login Performance
Incident window: February 13, 2016 08:30 UTC to February 22, 2016 12:45 UTC Impacted Cloud services:Login performance
API interactions
Impact Level : high
We have located and fixed the issue causing the vast publish failures over the last 2 weeks. Our infrastructure uses a log parsing server to consume, filter, and hold near realtime logs. Some time back we moved the infrastructure components to an asynchronous model to post logs to this service. Generally, the response times on the synchronous calls are quite low, but on occasion the number and quantity of log records pushed to the service would cause some latency in that API. That jitter was the main reason to move to an asynchronous model. In debugging the publish issue, we ultimately discovered that one code path was still posting directly to the logging service and, as noted above, at random intervals there could be an unexpected latency in the synchronous API used to do that post. The result is that we would see an intermittent ‘pause’ of up to 30 seconds when calling the log ingestion api. The internal timeout was 10 seconds, and this latency caused publish activity to halt. We did extend, as a workaround, the timeout to 15, and then 20 seconds. Those changes eased, but did not eliminate the failures seen by customers. As this was happening in only one code point, it took some time to ‘divide-by-two’ and get down to the internal function call that was causing the excessive wait. Also, 99% of calls in our testing environment ( and in production ) would not show the latency, making locating this anomaly somewhat challenging to find. On Wednesday, the 17th of Feb at 3:47PM GMT, we pushed an emergency change to production to disable the ‘happy path’ logging that was going directly to the logging service. Error logging was left enabled in order to maintain visibility to internal errors in the subject API. Note that we were not, and are not, seeing issues in that service. Latency issues caused the caller to abandon the request, even though the service was completing successfully, but slowly. The change to disable the logging in the normal flow had an immediate effect. The result of the change is that 99% of these calls are now completing in under 400ms. There are a few outliers taking up to 2000 ms. We have since observed no latency issues in the API. On the 22nd of Feb at 12:45 GMT we pushed a more permanent change to the component to use the asynchronous logging facility and have closed out our internal issue.
February 4, 2016
Maintenance window: February 04, 2016 00:01 UTC to February 04, 2016 04:00 UTC Impacted Cloud services:Identity services
Fix for Kony SDK refresh token not refreshing OAuth session
Impact Level : minor
No significant downtime is expected. The scheduled maintenance is designed for minimal disruption of service availability; however, it is possible for your service(s) to be unavailable for a short period of time during the maintenance window.
January 30, 2016
Maintenance window: January 30, 2016 05:01 UTC to January 30, 2016 09:00 UTC-
Security upgrades will be performed.
The ability to access the Cloud Management Console will not be available. However, your runtime environments and services will still be operational. There is no disruption to your end-user apps and the deployed runtime services and APIs they use. This outage is limited to the management console and is not expected to last the entirety of the maintenance window.
While the Cloud Management Console is unavailable you will not be able to perform the following:
Access the administration consoles for your Kony products.
Perform MobileFabric service deployments.
Kony Studio
You will be unable to log in using your Kony Cloud credentials. Logins using Studio license files will not be impacted.
You will be unable to perform application deployments to Kony Cloud.
Kony Visualizer
You will be unable to log in using your Kony Cloud credentials.
You will be unable to publish projects and/or share prototypes to Kony Cloud.
Analytics & Reporting services
Database capacity is being expanded.
During the maintenance window, reporting services will not be available, but analytics data will still be captured.
-
You will be unable to access the site while the maintenance is being performed.
Impact Level : high
We anticipate an outage for the Cloud Management Console within the maintenance window. Every effort will be made to minimize the duration of the outage. We estimate approximately 1-2 hours for the outage.
January 30, 2016
Maintenance window: January 30, 2016 00:01 UTC to January 30, 2016 04:00 UTCSync services
Due to a configuration change in some open-source packages, we are required to make infrastructure changes to support application deployment and scaling events.
If you already have custom code on your Sync server, you can republish to it to apply this fix yourself.
If you would like to schedule a different time for this fix to be applied, please open a support ticket using the Cloud Management Portal for each affected Cloud communicated to your organization via email.
Impact Level : minor
No significant downtime is expected. The scheduled maintenance is designed for minimal disruption of service availability; however, it is possible for your service(s) to be unavailable for a short period of time during the maintenance window. We anticipate any downtime lasting approximately ten minutes; this duration would be approximately the amount of time required to deploy an application.
January 25, 2016
Maintenance window: January 25, 2016 00:01 UTC to January 25, 2016 04:00 UTC Impacted Cloud services:Messaging services (Release Notes - to be updated for v6.5.0.6)
Apple universal certificate fix
Messaging API requiring basic authentication by default
The “Authentication for Message API” checkbox will be enabled for all Clouds by default. This checkbox is located under Configuration -> General -> Security section of the KMS Console and if disabled allows unauthenticated usage of the messaging(Push, Event) older model api (i.e. ./service api). If you are an existing customer and have not yet migrated to the newer api model(api/v1), we request you to consider taking this as top priority and do so. If for some reason, you want to continue using the older api model(/service/), you would need to pass Basic Authorization Header consisting of username/password in the headers and make the changes in the api calling code if any. If you have been already using the newer api model, this update would not have any impact for you. You may proactively enable this option by yourself prior to this update and we do not recommend disabling this option under most circumstances.
Note: if your applications must invoke the messaging API without basic authorization, then you will need to uncheck this checkbox after the update has been applied during the maintenance window.
Impact Level : minor
No significant downtime is expected. The scheduled maintenance is designed for minimal disruption of service availability; however, it is possible for your service(s) to be unavailable for a short period of time during the maintenance window.
January 23, 2016
Maintenance window: January 23, 2016 00:01 UTC to January 23, 2016 04:00 UTCSync services
Due to a configuration change in some open-source packages, we are required to make infrastructure changes to support application deployment and scaling events.
If you would like to schedule a different time for this fix to be applied, please open a support ticket using the Cloud Management Portal for each affected Cloud communicated to your organization via email.
Impact Level : minor
No significant downtime is expected. The scheduled maintenance is designed for minimal disruption of service availability; however, it is possible for your service(s) to be unavailable for a short period of time during the maintenance window. We anticipate any downtime lasting approximately ten minutes; this duration would be approximately the amount of time required to deploy an application.
January 21, 2016
Maintenance window: January 21, 2016 00:01 UTC to January 21, 2016 04:00 UTC Impacted Cloud services:SSL certs- updated for konycloud.com across all environments
Impact Level : minor
No significant downtime is expected. The scheduled maintenance is designed for minimal disruption of service availability; however, it is possible for your service(s) to be unavailable for a short period of time during the maintenance window.
January 21, 2016
Maintenance window: January 21, 2016 00:01 UTC to January 21, 2016 04:00 UTCApple universal certificate fix
Messaging API requiring basic authentication by default
The “Authentication for Message API” checkbox will be enabled for all Clouds by default. This checkbox is located under Configuration -> General -> Security section of the KMS Console and if disabled allows unauthenticated usage of the messaging(Push, Event) older model api (i.e. ./service api). If you are an existing customer and have not yet migrated to the newer api model(api/v1), we request you to consider taking this as top priority and do so. If for some reason, you want to continue using the older api model(/service/), you would need to pass Basic Authorization Header consisting of username/password in the headers and make the changes in the api calling code if any. If you have been already using the newer api model, this update would not have any impact for you. You may proactively enable this option by yourself prior to this update and we do not recommend disabling this option under most circumstances.
Note: if your applications must invoke the messaging API without basic authorization, then you will need to uncheck this checkbox after the update has been applied during the maintenance window.
Impact Level : minor
No significant downtime is expected. The scheduled maintenance is designed for minimal disruption of service availability; however, it is possible for your service(s) to be unavailable for a short period of time during the maintenance window.