Incident Management part 1: How Zendesk service issues become service incidents

This is part 1 of the Overview of incident management at Zendesk. This guide contains the following parts:

• Part 1: How Zendesk service issues become service incidents (this article)
• Part 2: How Zendesk manages service incidents
• Part 3: Monitoring a public Zendesk service incident
• Part 4: Post resolution incident analysis and reporting

In this article, part 1, you'll get an understanding of the service incident life cycle at Zendesk, starting from when an incident is detected or reported to the ways Zendesk teams communicate and escalate the incident internally to how incident remediation works.

Before a service incident is created at Zendesk, our Engineering team may receive an alert, or tickets  might be raised to Zendesk Customer Support team that indicates something unusual is happening.

Service incident creation workflow

These issues generally come from two sources: 

1. Zendesk Network Operating Center (ZNOC) receives an alert, which is then reviewed and validated by the Zendesk Product Engineering team for affected products (e.g., Support, Guide, Chat, Talk)

The ZNOC team has monitoring tools and processes to alert the Product Engineering team when there are issues with Zendesk products such as a product responding more slowly than expected, increased error rates, or if a service’s volume is changing at a greater rate than expected. Usually these alerts are the first indication that something is not working properly. The majority of service incidents are first discovered through the monitoring that Zendesk has built into our systems.

2. Customer Reports, routed through Zendesk Customer Support

Customer reports are another first indication that something isn't working properly. When customers notice Zendesk service issues, they report the issue using Zendesk's own internal support system or chatting with Zendesk Customer Support.

To make sure customer reported issues are handled appropriately, the Zendesk Customer Support team evaluates the reported issue and determines if it is part of an existing service incident, if a new service incident should be created, or if the issue reported should follow our standard troubleshooting path.

• If there is an existing incident, the customer ticket will be linked to that incident and the customer will be informed of the current status.
• If it's a new report, a new service incident will be created based on the severity scale (more in that in Part 2) and regular status updates sent to all linked tickets.
• If the issue is not caused by a potential Zendesk service incident, Zendesk Customer Support will help the customer troubleshoot the issue and resolve or escalate as appropriate.

Learn more

This completes Part 1, How Zendesk service issues become service incidents, of the Overview of incident management at Zendesk.

If you'd like to learn more, you can move on to the next part of this guide: Part 2: How Zendesk manages service incidents.