Start free

Customer support · USE CASE

Find ticket spikes your status page never mentioned.

Count Zendesk tickets per day, check each spike against your Statuspage incidents, and see what engineering should explain and which customers still need a reply.

Data sources
Assistant
Destination
Try it with your data Free with up to 3 data sources · No credit card
A WORKED EXAMPLE

Which busy support days never made it onto our status page?

Day (New York)TicketsStatus page
Nov 444No incident
Nov 938Major incident

Oct 17–Nov 13, 2026 · New York days · Read Nov 14, 15:00 UTC

Nov 4 had 44 tickets, nearly three times the median day, and nothing on the status page. Twenty-eight were about reminder emails, so ask engineering about that day first. The Nov 9 API incident was posted, but 7 of its 21 tickets still need a reply.

WHERE THE RESULT GOES

Google Sheets

Export each data source report to Google Sheets, then add your analysis or checklist to the review Sheet.

Example use case

Ask. Follow up.
Take the next step.

✦ AI assistantSample use case
ZendeskStatuspage
YOU

  1. 01
    44 tickets · 28 tagged reminders · No Statuspage incidentAsk engineering first

    Next

  2. 02
    38 tickets · 21 tagged api · Major incident, resolved that nightAnswer 7 waiting tickets

    Next

  3. 03
    32 tickets · 17 tagged billing · No Statuspage incidentFix the explanation

    Next

Oct 17–Nov 13, 2026 · New York days · Read Nov 14, 15:00 UTC

01 · CONNECT YOUR DATA

Your tools. One place to ask.

2 of 3 Free data sources
No credit card · Daily refresh

DatapipeYour project
Your AI assistantor a report in Sheets / Data Studio
  1. Create your free workspace

    Sign up with your company email. Your first project opens on Data sources.

  2. Add the data sources

    Choose the accounts for this use case. Authorize access and select the property or site.

  3. Bring your question

    Connect your project to a supported AI assistant, or build your source reports.

Create a free account →
Setup steps & what you need

Email/password signups confirm their email first. Use Google signup with a company account if you prefer.

  • Zendesk: Enter your Zendesk subdomain and authorize the intended account using its supported setup. Setup guide ↗
  • Statuspage: Paste a Statuspage API key, found under API info in your Statuspage account menu. Datapipe finds the status pages the key can see and reads incidents, components and page settings without changing them. Setup guide ↗

Free includes 3 data sources across the workspace. One account/property added to one project counts as one. Extra properties or the same account in another project use another slot.

02 · ASK A USEFUL QUESTION

Start with a prompt.
Follow the evidence.

Copy these in order into your connected assistant.
Each builds on the answer before it.

01

Count tickets per day and find the spikes

Read the full prompt
Use only this Datapipe project’s authorized data. Discover the connected accounts, datasets and compatible fields first. Confirm dates, timezones, currencies and data coverage. Keep missing or unmatched rows visible; never substitute sample data. Compare the sources explicitly and explain every match. Do not change source records or send messages.

From the connected Statuspage account, read Status pages and tell me the page name and time_zone. From the connected Zendesk account, read tickets_expanded with id, subject, type, status, problem_id, has_incidents, created_at and tags. Convert created_at, which Zendesk returns in UTC, to the status page’s time zone and count tickets per local day for the last 28 complete days. Report the median day and mark spike days that are at least 1.5 times the median and at least 10 tickets above it, unless I give you another rule. Say how many tickets fell outside the window. If the Zendesk read stops at its row limit, tell me instead of treating the counts as complete.
02

Check each spike against the status page

Read the full prompt
Read Statuspage incidents with incident_id, name, status, impact, created_at and resolved_at. Tell me how many incidents were returned; if it is exactly 100, warn me that older incidents may be missing. Treat the dates as days in the page’s time zone. For each spike day, list incidents other than maintenance created on or before that day and resolved on or after it, or still unresolved, and mark the day covered or not covered. Show maintenance separately, because its created date is when it was scheduled. Check the day before and after each incident as well. Then group each spike day’s tickets by tag and give the top tags with three sample subjects.
03

Prepare the spike review

Read the full prompt
Build one table with a row per spike day: date, tickets, median day, top tag and its count, covering incident or none, tickets still open or pending, and tickets linked to a problem ticket (type incident with a problem_id). Then prepare three lists. Uncovered spikes: the question for engineering, with sample subjects and ticket IDs. Posted incidents: open or pending tickets agents still need to answer. Other causes: the team that should explain the change. Treat tags as clues, not proof of cause. Draft everything in this conversation. Do not change tickets, link them to a problem ticket or post on Statuspage.
Need to connect your assistant?Claude guide ↗ChatGPT guide ↗

03 · USE WHAT YOU FIND

Send uncovered spikes to engineering and waiting tickets to agents.

  1. 01

    Count Zendesk tickets per day in the status page’s time zone.

  2. 02

    Check each spike day against Statuspage incidents.

  3. 03

    Send uncovered spikes to engineering and waiting tickets to agents.

Check the result at your next review.

Run the same count at next week’s review. The 14 waiting reminder tickets and the 7 API tickets should be solved or have a reason to stay open. If engineering confirms a reminder fault, check that a backfilled incident now covers Nov 4. For the next spike, check that an incident went up the same day and that its tickets are linked to one problem ticket.

Implementation tips for this use case

For a spike with no incident, give engineering the day, the main tag, sample subjects and ticket IDs, and ask whether something broke. If it did, the support lead opens one problem ticket and links the waiting tickets, and the status page owner decides whether to backfill an incident. For posted incidents, list tickets still open or pending and tickets not linked to a problem ticket so agents can reply. Spikes with another cause go to the team that owns it. Copy the agreed review to the team’s Sheet.

WHEN YOU NEED MORE CONTEXT

Go a little deeper.

The method and reporting checks
behind this example.

How to compare Zendesk ticket spikes with Statuspage incidents

  1. Count Zendesk tickets per day in the status page’s time zone.

    Add the Zendesk account and the Statuspage account to one project. Read Expanded current tickets with ID, subject, type, status, problem ID, created time and tags. Zendesk returns current tickets that are not archived, whatever the report dates, with created times in UTC; past 10,000 rows the read stops with an error rather than returning part of the list. Read Status pages for the page’s time zone, convert each ticket’s created time to that zone and count tickets per day for the last 28 complete days. Mark days at least 1.5 times the median day and at least 10 tickets above it, or use your team’s own rule.

  2. Check each spike day against Statuspage incidents.

    Read Incidents & outages with name, status, impact, created and resolved dates. The read returns up to 100 incidents from the first status page the key can see, with dates as Statuspage reports them, in the page’s time zone. A spike day is covered when an incident other than maintenance was created on or before that day and resolved on or after it, or is still unresolved. Keep maintenance aside: its created date is when it was scheduled. Look at the day before and after each incident too. Then group the spike day’s tickets by tag to see what customers wrote about.

  3. Send uncovered spikes to engineering and waiting tickets to agents.

    For a spike with no incident, give engineering the day, the main tag, sample subjects and ticket IDs, and ask whether something broke. If it did, the support lead opens one problem ticket and links the waiting tickets, and the status page owner decides whether to backfill an incident. For posted incidents, list tickets still open or pending and tickets not linked to a problem ticket so agents can reply. Spikes with another cause go to the team that owns it. Copy the agreed review to the team’s Sheet.

See the complete example report
EXAMPLE REPORT

Which busy support days never made it onto our status page?

Oct 17–Nov 13, 2026 · New York days · Read Nov 14, 15:00 UTC

Which busy support days never made it onto our status page?
Day (New York)TicketsStatus page
Nov 444No incident
Nov 938Major incident
WHAT TO LOOK ATNov 4 had 44 tickets, nearly three times the median day, and nothing on the status page. Twenty-eight were about reminder emails, so ask engineering about that day first. The Nov 9 API incident was posted, but 7 of its 21 tickets still need a reply.

Send uncovered spikes to engineering and waiting tickets to agents.

Nov 4 had 44 tickets against a median day of 15. Twenty-eight were tagged reminders, and 4 more arrived on Nov 5. Of those 32 tickets, 14 are still open or pending: 12 from Nov 4 and 2 from Nov 5. No Statuspage incident covers Nov 4 or Nov 5. Statuspage shows a major incident, “Elevated API error rates”, created and resolved on Nov 9 in New York time. Twenty-one api tickets arrived between 8:15 and 11:35 pm New York time. None is linked to a problem ticket, and 7 are still open or pending. Seventeen tickets asked about the new invoice layout, and 6 are still open. There is no Statuspage incident, and the subjects describe a change customers did not expect rather than a service fault.

Try the example with sample CSVs

Fictional rows matching the example above. Attach these files to your assistant for a sample analysis.

Data method, reporting checks & sources

Add the Zendesk account and the Statuspage account to one project. Read Expanded current tickets with ID, subject, type, status, problem ID, created time and tags. Zendesk returns current tickets that are not archived, whatever the report dates, with created times in UTC; past 10,000 rows the read stops with an error rather than returning part of the list. Read Status pages for the page’s time zone, convert each ticket’s created time to that zone and count tickets per day for the last 28 complete days. Mark days at least 1.5 times the median day and at least 10 tickets above it, or use your team’s own rule. Read Incidents & outages with name, status, impact, created and resolved dates. The read returns up to 100 incidents from the first status page the key can see, with dates as Statuspage reports them, in the page’s time zone. A spike day is covered when an incident other than maintenance was created on or before that day and resolved on or after it, or is still unresolved. Keep maintenance aside: its created date is when it was scheduled. Look at the day before and after each incident too. Then group the spike day’s tickets by tag to see what customers wrote about. For a spike with no incident, give engineering the day, the main tag, sample subjects and ticket IDs, and ask whether something broke. If it did, the support lead opens one problem ticket and links the waiting tickets, and the status page owner decides whether to backfill an incident. For posted incidents, list tickets still open or pending and tickets not linked to a problem ticket so agents can reply. Spikes with another cause go to the team that owns it. Copy the agreed review to the team’s Sheet.

Tickets are counted per day in the status page’s time zone, not by UTC date. Maintenance stays aside, because its created date is when it was scheduled. Coverage is judged from Statuspage days; ticket tags are clues, not proof of cause. Both reads are current records with limits: unarchived tickets, and up to 100 incidents from the first status page.

  • Tickets are counted per day in the status page’s time zone, not by UTC date.
  • Maintenance stays aside, because its created date is when it was scheduled.
  • Coverage is judged from Statuspage days; ticket tags are clues, not proof of cause.
  • Both reads are current records with limits: unarchived tickets, and up to 100 incidents from the first status page.
  • Access to the intended Zendesk account or property.
  • Access to the intended Statuspage account or property.
  • Tickets are counted per day in the status page’s time zone, not by UTC date.

For blended reports, align dates, normalized URLs, and reporting grain. Query-level search rows must not duplicate page-level sessions.

Zendesk tickets: type, problem_id, status and archived tickets ↗Zendesk: working with problem and incident tickets ↗Statuspage API: incidents and impact values ↗Statuspage: backfill an incident ↗Report starting points ↗

A FEW USEFUL ANSWERS

Before you start.

Why do I need both Zendesk and Statuspage?

Zendesk shows when customers noticed something and what they wrote about. Statuspage shows what you told them. Tickets alone cannot tell you whether a busy day was announced, and the status page alone cannot show the problems nobody posted.

Why count tickets in the status page’s time zone?

Zendesk returns created times in UTC, while Statuspage reports dates in the page’s time zone. In the example, the API tickets arrived on the evening of Nov 9 in New York, which is Nov 10 in UTC. Counting by UTC day would make the incident look quiet and invent a spike on Nov 10.

Does a spike without an incident mean we had an outage?

No. Nov 12 in the example was a new invoice layout, not a fault. Read the subjects and tags, then ask the owning team before posting anything.

How are tickets matched to Statuspage incidents?

By day only. The two tools share no ID, so the review compares incident dates with ticket days and uses tags to see what customers wrote about. Zendesk’s own incident ticket type is separate: it links duplicate tickets to one problem ticket.

What if we have more than one status page?

Incidents are read from the first status page the API key can see, up to 100 of them. If your team keeps several pages, check that the returned page is the one customers use.

Does the assistant post incidents or link tickets?

No. It prepares the review in your conversation. Your support lead links tickets in Zendesk, and the status page owner decides what to post.

YOUR NEXT STEP

Try it with your own data.

Start free with up to 3 data sources. No credit card.

Start free →