Zendesk Explore Data Refresh
Someone in your morning standup says the dashboard is wrong. A view shows 42 open tickets, Explore says 38, and the next ten minutes go to a discussion about whether the reporting is broken.
It usually is not. Explore is not a live window onto Zendesk — it is a data warehouse fed by a scheduled sync, and every report you open is a snapshot from the last time that sync finished. The gap between those two numbers is almost always the sync interval, not an error.
That distinction matters more than it sounds. Once you know how the refresh actually behaves, you can tell within about thirty seconds whether a discrepancy is a timing artefact you should ignore or a data problem you should chase — and you can stop designing dashboards that promise a freshness they cannot deliver.
What this guide covers
- How often Explore refreshes on your plan
- Why an “hourly” refresh can be four hours old
- The 30-day rule that silently drops accounts to weekly
- How to check exactly how stale a report is
- A decision process for telling sync lag from a real error
- What to do when the work genuinely needs live numbers
This is the reason behind a caveat that appears in most of our reports in the support metrics dashboard: snapshot metrics are accurate as of the last sync, not as of now.
Refresh intervals by plan
Historical reporting data syncs either daily or hourly, depending entirely on plan.
| Plan | Refresh interval |
|---|---|
| Suite Team | Daily |
| Suite Growth | Daily |
| Suite Professional | Hourly |
| Suite Enterprise | Hourly |
| Suite Enterprise Plus | Hourly |
| Explore Lite | Daily |
| Explore Professional | Hourly |
| Explore Enterprise | Hourly |
Daily means one update per day at midnight in the account’s timezone. The practical consequence is significant and often missed: on a daily plan, nothing that happened today is in Explore. A morning queue review is reading yesterday’s close of business. That is fine for trend reporting and useless for triage, and no amount of dashboard design fixes it.
Hourly does not mean on the hour. A new sync starts one hour after the previous one finished, and the start time is randomised within that hour. So the interval floats, and it drifts through the day.
Why “hourly” can mean four hours
This is the part that generates the most confusion, and it is worth understanding precisely because it explains the discrepancies people report most often.
A sync can itself take more than two hours on a busy account. Since the next sync only starts an hour after the previous one ends, a slow sync pushes everything back. Two consecutive slow syncs can leave data up to about four hours old on a plan documented as hourly.
There is a second, subtler effect. If a ticket is updated while a sync is running, that update may not be captured by the sync in progress — it lands in the next one. Zendesk’s own worked example:
- 1:00pm — sync starts
- 1:30pm — a ticket field is updated
- 2:00pm — sync ends, and the field is still blank in Explore
- 3:00pm — next sync starts
- 3:45pm — sync ends, and the field finally appears
The ticket was updated at 1:30pm and became reportable at 3:45pm. Nothing failed. If you are investigating “the report is missing a change I just made”, this is almost always what happened, and waiting one more cycle is the entire fix.
The 30-day rule that catches everyone
Here is the behaviour most likely to make a dashboard look badly broken.
If no report or dashboard in the account is accessed for more than 30 days, the refresh interval automatically drops to weekly. It restores to normal as soon as someone opens a report or dashboard — but the data you see immediately after that is up to a week old, and it stays visibly stale until the next sync completes.
Where this bites: seasonal or quarterly reporting. A dashboard built for a quarterly business review, left untouched for six weeks, then opened the morning of the meeting, will show week-old numbers. It is not a bug and it is not recoverable in the moment.
The prevention is straightforward. A scheduled dashboard delivery counts as access. Put any dashboard you care about on a weekly email schedule — even to yourself, even if you never read it — and the account never falls into weekly refresh. This is the single cheapest piece of Explore hygiene available and it takes a minute to set up. It pairs well with the cadence in Zendesk reporting cadence.
Live data is a separate system
Near-real-time data in Explore is not a faster version of the sync. It is a different mechanism with different rules.
Live dashboards and live data widgets refresh in near-real time, typically every 5 to 10 seconds, though network speed and ticket volume affect that. The important limitations:
- Live data widgets require Explore Enterprise.
- The prebuilt Explore live dashboard is restricted by account history. It is available to users who accessed Explore before May 5, 2026; newer accounts use the real-time monitoring dashboards instead.
- Live and historical numbers will not match. They are different pipelines measuring at different moments. Putting them side by side on one dashboard invites exactly the argument this guide is meant to end.
- Live dashboards cover a narrow metric set — agents online, conversations in queue, wait times. They are for monitoring right now, not analysis.
Note also that on the live dashboard, messaging metrics exclude social channels such as WhatsApp, Facebook Messenger, and SMS. If you monitor a social-heavy queue there, you are watching an incomplete picture — see Zendesk messaging report.
The rule worth adopting: use live data to decide what to do in the next ten minutes, and historical data to decide what to do this month. Never use one to audit the other.
How to check how stale a report is
Explore tells you, and almost nobody looks.
The last updated timestamp in the query builder shows when the most recent sync ended. A report reading “last updated 30 minutes ago” means the sync finished half an hour back, so any change made in the last 30 minutes — plus anything caught mid-sync before that — is not in the report yet.
Make this visible rather than tribal knowledge. Two habits help:
- Put the refresh expectation in the dashboard title or a text widget. “Backlog — hourly sync, not live” prevents most of these conversations before they start.
- Never label a scheduled snapshot as current. A dashboard headed “Open tickets right now” on a daily-refresh plan is making a promise Explore cannot keep.
Sync lag or real error?
When a number looks wrong, work through this in order. It takes under a minute and resolves the large majority of cases.
| Check | If yes |
|---|---|
| Is the gap smaller than your refresh interval? | Sync lag. Ignore it. |
| Was the change made in the last couple of hours? | Likely mid-sync. Wait one cycle. |
| Has nobody opened a report in a month? | Weekly downgrade. Open one, wait, re-check. |
| Are you comparing a live widget to a historical report? | Different pipelines. Not comparable. |
| Is it a snapshot metric compared against a live view? | Expected. Snapshots are as-of-sync. |
| Does the gap persist after two full sync cycles? | Now investigate for real. |
Only the last row justifies a support ticket. If a discrepancy survives two complete syncs, look at the report definition before the data: wrong dataset, an unnoticed filter, a COUNT where D_COUNT belongs, or a calculated metric with an unintended condition. Zendesk Explore calculated metrics covers the formula-side causes, and when Zendesk metrics disagree covers reconciliation across metrics.
Designing around the sync
You cannot make Explore faster, so build reporting that does not need it to be.
Match the report to the interval. Daily-refresh accounts should not run intraday operational reviews from Explore. Use Zendesk views for live triage and Explore for trends. Trying to do both from one surface is where the frustration comes from.
Prefer trends over snapshots for anything shared. A weekly trend line is unaffected by whether the last sync landed twenty minutes ago. A live count is wrong the moment you screenshot it. This is also why the aging distributions in the Zendesk backlog aging report travel better in a deck than an open-ticket total.
Keep operational monitoring in Zendesk. Views, triggers, and automations act on live state. If the requirement is “alert me when an urgent ticket goes unassigned”, that is a trigger, not a dashboard — see Zendesk unassigned tickets report for the reporting half of that pairing.
Schedule one delivery per important dashboard. Guards against the weekly downgrade and gives you a dated record of what the numbers said, which is quietly useful when someone asks why last month’s figure changed.
Set expectations once, in writing. A single line in your reporting documentation — “Explore syncs hourly; views are live; they will not match” — prevents the same discussion recurring monthly.
Common mistakes
- Treating Explore as live. It is a warehouse on a schedule. Views are live; reports are not.
- Not knowing your interval. Daily-plan accounts cannot report on today at all.
- Assuming hourly means punctual. The window floats and slow syncs can stretch it to hours.
- Letting dashboards go untouched for a month. The silent weekly downgrade lands right when you need the data.
- Comparing live widgets with historical reports. Different pipelines, different moments, no reconciliation possible.
- Labelling snapshots as “current”. Sets up an expectation the sync will break.
- Escalating before two full cycles. Most reported discrepancies resolve themselves.
- Monitoring social messaging on the live dashboard. WhatsApp, Messenger, and SMS are excluded there.
Where this fits in your reporting
- Zendesk Explore calculated metrics — the other main source of numbers that look wrong
- Zendesk Explore dashboard migration checklist — auditing what you actually rely on
- Zendesk backlog report — a snapshot metric affected by sync timing
- Zendesk unassigned tickets report — where live views beat reports
- When Zendesk metrics disagree — reconciling across metrics
- Zendesk Explore pricing — what each plan tier includes
- support metrics dashboard — the hub
FAQ
How often does Zendesk Explore refresh? Daily at midnight account time on Suite Team, Suite Growth, and Explore Lite. Hourly on Suite Professional and above and on Explore Professional and Enterprise, where a new sync begins an hour after the previous one ends.
Why is my hourly data more than an hour old? Because the next sync starts an hour after the last one finishes, and a sync can take over two hours. Consecutive slow syncs can leave data around four hours old.
Why is a change I just made missing? Updates made while a sync is running are usually picked up by the following sync, not the current one. Wait one cycle.
Can I force a refresh? No. The sync schedule is not user-triggerable. Opening a report restores a downgraded interval but does not trigger an immediate sync.
Why did my data become a week old? No report or dashboard was accessed for 30 days, which drops the account to weekly refresh. Schedule a recurring dashboard delivery to prevent it — deliveries count as access.
Which plans get real-time data? Live data widgets require Explore Enterprise. The prebuilt live dashboard is limited to users who accessed Explore before May 5, 2026; other accounts use real-time monitoring dashboards.
Should live and historical numbers match? No. They are separate pipelines measured at different moments. Use live for monitoring, historical for analysis, and do not audit one with the other.
Get support metrics that refresh without you managing a sync - start free