Your Kayako Classic OnDemand instance is going down or having major performance issues causing disruption to your operations, and you would like to ensure that the issue is addressed.
If you are experiencing outages with your Kayako Classic OnDemand environment, please raise a Support ticket including as much of the following information as possible:
- The name of your Kayako instance; e.g.: example.kayako.com
- A timeline of the issue experienced: Is the issue recurring? When were the outages observed and how long did they last?
- A HAR file with the reproduction of the issue.
- Any additional information regarding errors observed, degraded performance, etc.
Once your ticket has been received, we will proceed to engage the Infrastructures Team to address the issue and ensure a solution is reached.
If you receive a ticket reporting an outage of an OnDemand instance, please verify the following:
- The outage is still ongoing on the customer's site. Note that you may skip this step if the customer is reporting repeated outages in a certain time period.
- Check that the SaaS Team is not aware of the outage and that the server is not undergoing maintenance in the Kayako - SaasOps Google space.
When searching JIRA for reported incidents, it is a good idea to review the affected pod domain mentioned in the JIRA, and the customer domain using nslookup. This is done to confirm the affected pod and customer domain use the same address/IP. See the example below.
After this, you may escalate the issue to the SaaS Team as per the Kayako Classic Component Routing Table, including all the information gathered in your request, and inform the customer accordingly.
Note that a customer may request credit for their downtime. If they do, please refer to the article on Processing Customer Credit Requests for SLA Downtime to address their request.
RCA Note: Generally, the RCA documents for any incident are meant to be internal and the only public information is added to the Status Page. Therefore, if a customer asks for specific details on the RCA, we should explain that this is internal information, and provide a broad description of what happened without any specific details (e.g. one of the services was misconfigured and needed to be restarted).