Admin Pro Tip: Performance - Why is Zendesk Slow?

Performance is one of the most underrated, yet critically important, aspects of a well-functioning Zendesk instance. A slow platform can frustrate agents, increase handling time and ultimately have a negative impact on the customer experience. Performance challenges rarely have a single cause; typically they are due to a combination of data volumes, configuration and usage patterns. It is therefore rarely solely a Zendesk problem.
This article reviews the most common causes of slow performance in Zendesk, methods for identifying the causes, and best practice for keeping the system fast.

The usual culprits: why Zendesk feels slow

Before the problem can be solved, the cause must be understood. There are a number of recurring causes that are often involved when agents experience Zendesk as slow.

Too much data in views

This is one of the most common causes. A view that returns thousands of tickets can result in markedly slower loading. Each time an agent opens the view, or the view refreshes automatically, Zendesk has to fetch large amounts of data, and the browser has to render them.

• Classic example: A view named "All Unsolved Tickets", with no time limit, showing all open, pending and on-hold tickets across the entire lifetime of the system. Over time, the view can grow to 10,000+ tickets.
• Why it is a problem: Each column in a view (custom fields, comments, tags) requires database queries. When the number of tickets is multiplied by the number of columns, a very large number of data points arise that have to be fetched and processed simultaneously.

Complex macros and automations

Macros and automations are central features in Zendesk, but they can affect performance when they become too heavy. A macro that performs many actions (e.g. updating several custom fields, notifications to webhooks and internal notifications) can take a significant time to execute.

• The invisible delay: When an agent runs a heavy macro, a delay can occur while Zendesk processes the actions in the background. The wait can be experienced as system slowness.
• Automations in chains: An automation that updates a ticket can trigger other automations. These chain reactions can create unexpected delays and, in the worst case, timeouts.

Third-party apps and integrations

The Zendesk Marketplace can be a great help, but each installed app adds code to the Zendesk instance. A poorly coded or resource-intensive app can affect performance, especially in the agent interface.

• Apps in the ticket view: Many apps load data into the side panel for each ticket. If an app fetches data from an external, slow API every time it opens, it can slow down the experience.
• Webhooks and integrations: Integrations that continuously send data back and forth can create constant background load. If an external system is slow, Zendesk can feel slow while a response is awaited.

Poorly optimised Explore reports

Explore is a powerful tool, but it can load the database. Complex reports that run on large amounts of data can be slow to open and can simultaneously affect the general performance of the Zendesk account.

• "Slow queries": When a report takes more than a few minutes to run, it can be classified as a "slow query". These queries can tie up resources and affect other parts of the system.
• Too many calculated metrics: A report with many complex calculated metrics typically takes longer to generate than a report with simple standard metrics.

Agent behaviour and tool usage

In some cases, perceived slowness is due to usage patterns rather than system configuration.

• Too many open tabs: Many open Zendesk tabs (e.g. 20+) can cause slowness, as each tab runs its own processes and updates, which load the browser and the connection to Zendesk.
• Poor search habits: Broad searching across the whole system, rather than effective use of views and filters, can be resource-intensive.

Browser problems and local factors

The local environment should always be investigated.

• Outdated browser: Older browser versions can have poor performance with modern web applications such as Zendesk.
• Browser extensions: Ad-blockers or other extensions can conflict with Zendesk scripts and make the page slower.
• Network problems: A slow or unstable internet connection at the individual agent is a classic and often overlooked cause.

The hunt for slow queries: dive into Explore

Explore is not only for reporting, but also a central tool for diagnosing performance problems related to data queries. Zendesk provides functionality that can identify the reports that load the system the most.

What is a "slow query"?

A "slow query" is a report query that takes an unusually long time to execute in the Zendesk database. Zendesk monitors this internally, and if a query takes too long, it can be de-prioritised or interrupted to protect overall stability. Many slow queries are a clear warning sign for administration.

Find slow reports in Explore

The process requires admin access to Explore.

Step 1: Go to report history

1. Navigate to Zendesk Explore.
2. Click the report icon (top left) to open the report library.
3. Find the report suspected of being slow (or any report to see the feature).
4. Click the three dots (...) next to the report name and select Report history.

Step 2: Filter by execution time
In Report history, you can see when the report has been run, by whom, and how long it took.

1. Click the filter icon (the funnel) at the top right of the list.
2. Find the Execution time field (or equivalent; the name may vary).
3. Set a filter so that only runs over e.g. 60 seconds are shown.

Step 3: Analyse the causes
The list shows the times when the report has been slow. The method can be applied to central dashboards and reports, especially those with large amounts of data or complex calculations, to identify the biggest loads.

Practical example: a very slow first reply time report

A report intended to show "Average time to first reply (FCR) per agent" was built as follows:

• Dataset: Support
• Metric: CALC - Avg first reply time (hrs) (complex calculated metric)
• Row: Ticket assignee
• Filter: Ticket created - Previous 12 months

The challenge was that "Previous 12 months" on a large account could mean hundreds of thousands of tickets. The calculated metric was already heavy, and the combination with the large amount of data meant that the report consistently took 5–10 minutes to load. The report was almost unusable and loaded the system with every refresh of the dashboard.

The solution was to narrow the time frame. The filter was changed to "Previous 3 months", and separate, smaller reports were created for historical analysis. After this, the report ran in under 10 seconds.

How to optimise Explore queries

Once slow reports have been identified, the following optimisations can be applied:

• Narrow the time range: The most effective method. A report for "last 7 days" is almost always faster than "last 12 months". A standard time filter on dashboards (e.g. "last 30 days") can be considered.
• Reduce the number of rows/columns: A report with many rows (e.g. 50 agents) is heavier than one with few (e.g. 5). Data can be grouped at a higher level if possible, e.g. by group instead of by agent.
• Simplify calculated metrics: Review CALC metrics. Avoid nested IF statements and complex logic where possible. In some cases, two simpler metrics are better than one complex one.
• Use attributes instead of metrics for filtering: Filtering on e.g. status should be done via the Ticket status attribute rather than creating a metric and filtering on it. Attribute filters are generally faster.

Views that kill performance: the hidden enemy

Where Explore reports can load the system in the background, slow views create direct and persistent frustration in the agents' daily work. Optimising views is often the quickest route to noticeable improvements.

The problem with "All Unsolved Tickets"

This type of view is a typical performance load. A view with e.g. 15 columns and 8,000 tickets requires extensive sorting and rendering. When sorting by a column, Zendesk has to sort all rows, and when scrolling, the browser has to handle a very large HTML table.

Experience: There are cases where a single heavy view makes the entire agent tab in Zendesk "sluggish", even when working in other views.

Dynamic content and too many columns

The more columns a view has, the more data has to be fetched and rendered. Columns with dynamic content are particularly heavy:

• Custom dropdown fields: Require additional lookups to display the selected value.
• Calculations in the view name: Using {{ticket.ticket_field_...}} in the view name can force the system to perform calculations for each ticket.
• Rich content fields: Fields with long text or images should be avoided in views.

Custom fields in views

Each custom field in a view can trigger additional database queries. A view with many custom fields is therefore markedly slower than a view with standard fields. The relevance should be assessed: is the information necessary in the overview, or can it be found by opening the ticket?

Best practices for fast views

The following checklist can be used to create faster views:

• Keep it simple: Use as few columns as possible, and show only what is necessary to identify and prioritise the next ticket.
• Use filters effectively: Replace broad views with specialised views, e.g.:
  • "My New Tickets" (assigned, status: new)
  • "My Open Tickets - Overdue" (assigned, status: open, overdue: yes)
  • "Unsolved Tickets - Last 7 Days" (status: open/pending, created: > 7 days ago)
• Limit the number of rows: A view with 100 tickets is faster than one with 10,000. Filters can be used to narrow the work.
• Avoid sorting on heavy columns: Sorting by "Updated" or "Created" is typically fast. Sorting by complex custom fields can be slow.
• Review views regularly: A quarterly review can reveal views that are no longer used or that have become too large. Unnecessary views can be deleted to reduce complexity.

Be proactive, not reactive: checks that prevent disasters

The best way to handle performance problems is to prevent them. Proactive checks can be built into fixed routines.

Monthly performance audit

A fixed, monthly "performance audit" can be carried out without being extensive:

1. Explore check: Apply "slow query" filters in Explore. Have new reports become slow?
2. View check: Sort views by number of tickets. Have any views grown markedly? Can they be narrowed with time filters?
3. App check: Go to Admin Center > Apps > Zendesk Support apps. Apps that are no longer used can be deactivated and removed.

Monitoring new apps and integrations

Before installing new apps in production, key questions should be clarified:

• What exactly does the app do?
• Does it fetch data from external sources, and how often?
• Do reviews mention performance problems?
• Can the app be tested in a sandbox environment first?

A practice can be applied where new apps are tested in a sandbox for a week while load times and errors in the browser console are monitored.

Review of automations and triggers

Automations and triggers can become outdated or inefficient. A review every 6 months can include:

• Have any become redundant after process changes?
• Do any run unnecessarily often (e.g. a trigger on "All ticket updates", but only relevant for "New tickets")?
• Can the order of conditions be optimised? Zendesk evaluates conditions from top to bottom; the most specific and likely conditions should be placed first.

Agent feedback is valuable

A simple channel for feedback on performance can be established, e.g. a Slack channel or a dedicated field in an internal feedback form. When slowness is reported, the following can be clarified:

• When did it occur?
• What action was being attempted?
• Which view/dashboard was open?
• Has it been tested in another browser or an incognito tab?

The information can be crucial for diagnosing the cause.

Set up alerts on Explore performance

With access to Zendesk APIs or more advanced monitoring tools, alerts can be set up if a particular Explore report uses more than e.g. 120 seconds. This is an advanced method, but it can be an effective proactive approach.

Measure what can be managed: effective performance measurement

Optimisation requires measurement. A systematic approach makes it possible to document improvements and identify problems.

Qualitative vs. quantitative measurements

A distinction can be made between:

• Quantitative: Objective figures, e.g. how many seconds a view takes to load, or how long a report takes to run.
• Qualitative: The agents' experience of speed and friction. Subjective, but often decisive.

An effective performance strategy combines both.

Quantitative tools and metrics

1. Explore execution times
Report history is the primary tool. Figures can be logged monthly in a simple spreadsheet for the most important reports to detect increases over time.

2. Browser Developer Tools (Network tab)
A free and powerful tool in modern browsers.

• Procedure:
  1. Open Zendesk in Chrome or Firefox.
  2. Open Developer Tools (F12 or Ctrl+Shift+I / Cmd+Opt+I).
  3. Go to the Network tab.
  4. Enable Disable cache for a fair test.
  5. Reload the page (Ctrl+R or F5).
  6. Wait until the page has finished loading.
• Areas of focus:
  • Waterfall: Shows when files and API calls are fetched. A long, thin "waterfall" can indicate many sequential calls.
  • The Time column: Sort to find the slowest calls. It could be calls to tickets.json or to third-party apps.
  • Total time: At the bottom, the total time and data volume are shown. This can be used as a baseline before and after optimisation.

3. Zendesk's built-in tools
Zendesk continuously expands monitoring. Admin Center > Objects and rules > Audits can in some cases contain performance-related events.

Qualitative measurements: the agent experience

The agents' experience should be actively included:

• Regular check-ins: Team leads or super users can be asked whether the speed is experienced as stable, and whether specific views are slow.
• Anonymous surveys: Quarterly surveys can include questions such as "On a scale of 1-5, how fast does Zendesk feel?" and "Are there specific actions that feel slow?"

Establish a performance baseline

Without a baseline, it is difficult to assess development. The load time for the most-used view and the most important dashboard can be measured via the Network tab and noted. When changes are made (e.g. removing an app or optimising a view), it can be measured again to document the effect, for example that the load time for "My New Tickets" has been reduced by 40%.

Red flags: when the system is slow and no one knows why

For sudden performance problems, it is important to work systematically. The following scenarios are typical:

• 🚩 Sudden, global slowness for all agents:

  • Suspects: A recent rollout (new app, new trigger), a general Zendesk service disruption (check status.zendesk.com) or an internal network problem.
  • Action: Check the Zendesk status immediately. Roll back the most recent change. Obtain the precise start time from agents.

• 🚩 Only one agent is affected:

  • Suspects: A local problem (browser, cache, extensions, network).
  • Action: Test in an incognito tab, another browser or another computer. If it works, it is local. Clear the cache and disable extensions.

• 🚩 Slowness occurs at specific times (e.g. 9 a.m. every morning):

  • Suspects: Scheduled tasks that load the system (a massive import script, a time-based automation that hits many tickets, or an external system that synchronises at the same time).
  • Action: Review scheduled tasks and time-based automations. Assess whether the timing matches.

• 🚩 Only one specific page/view is slow:

  • Suspects: A specific configuration (a heavy view, a complex macro or an app that only loads on that page).
  • Action: Use the Network tab on the specific page to identify slow calls. Remove columns from the view one at a time to isolate the cause.

• 🚩 No changes have been made, but it has become slower over time:

  • Suspects: Organic growth in data volumes. Views and reports gradually become larger and slower.
  • Action: Indicates a need for a performance audit. Review the largest views and reports and narrow them with time filters.

Green flags: signs of a fast and well-functioning system

Success can be recognised by the following signs:

• ✅ Consistent and predictable load times: Tickets open in 2–3 seconds regardless of the time of day, without unexpected "hangs".
• ✅ Proactive optimisation is part of the culture: Performance is discussed before it becomes a problem, and is part of ongoing operations.
• ✅ Clear ownership of performance: It is clear who to contact in the event of slowness, and there is a clear process for reporting and investigation.
• ✅ Few or no complaints about speed: Speed is not a recurring daily topic.
• ✅ Dashboards and reports are responsive: Central dashboards can be opened and refreshed in under 30 seconds.
• ✅ New tools are evaluated for performance: The performance impact is assessed early for new apps and changes.

Conclusion: performance is a journey, not a destination

A high-performing Zendesk instance is achieved and maintained through ongoing work. By understanding the typical causes, applying the right tools for diagnosis and building proactive checks into routines, performance work can be moved from reactive troubleshooting to controlled operation.

Every millisecond saved for an agent can be spent helping a customer. A fast platform can contribute to more satisfied agents, shorter resolution times and a better customer experience.