Is Zendesk Down? How to Tell
Is Zendesk down? Before you post an apology or open a ticket, spend two minutes finding out whether the problem is Zendesk, your network, or one tired browser tab.
Is Zendesk down? Check your pod, not the headline
Zendesk runs accounts across separate infrastructure groups, usually called pods, and your account lives on one of them. That matters more than most people realise. A green overall status can sit happily next to your own instance being unreachable, because the incident is confined to a pod that is not yours, or to one that is.
So find your pod first and check that specifically. The status page lists components by service too, which is how you learn that ticketing is fine and it is email delivery or the messaging widget that has fallen over.
Subscribe to updates for your pod now, while nothing is wrong. Hunting for a status page during an incident is time you do not have, and the subscription costs you one email.
Our fuller playbook for the incident itself, including the reconciliation afterwards, lives in Zendesk status and outages.
Five checks that separate you from them
Run these in order. Most of the time you will have your answer before check three.
The failures that look like an outage and are not
This is the list worth keeping, because every item on it has been mistaken for a Zendesk outage by somebody having a bad morning.
What to tell customers while you wait
Say something before they ask. A one-line banner on your site and a short note on whichever social account you actually run will prevent a meaningful share of the contacts you'd otherwise field twice.
Keep the wording plain. You are having a problem with your support system, you are aware, and you'll update by a specific time. Do not promise a restoration time you cannot control, because you're downstream of somebody else's incident and their estimate is not yours to repeat.
Keep a plain mailbox that still receives email whatever happens. It needs reconciling afterwards, and it is a great deal better than losing the messages.
Then write down what you did, with timestamps. When the queue floods on recovery, that timeline is the difference between an hour of cleanup and a day of it.
When it really is Zendesk
Once the status page confirms it, stop investigating. There's nothing on your side to fix and every minute spent reloading is a minute not spent on the customers.
Subscribe to the incident so updates come to you. Tell your team the diagnosis in one message, because otherwise five agents each run the same five checks. Point your fallback inbox at whoever is going to work it, and agree what you are doing with anything urgent that arrives in the meantime.
Don't open a support ticket for an incident that's already published. It adds nothing, it sits behind everyone else who did the same thing, and Zendesk's own queue is having a worse morning than yours. Open one only when your symptoms don't match anything on the status page, and when you do, include your subdomain, your pod, exact timestamps with a time zone and the specific request that failed.
Afterwards, read the postmortem if one appears. Not out of curiosity: it tells you whether the affected component is one you depend on heavily, which is useful the next time somebody asks whether you need a fallback plan.
Frequently asked questions
What's the fastest Zendesk outage check?
Open status.zendesk.com and find your pod. If that's green and Zendesk is not working for you, the cause is almost always local: network, extension or a recent change somebody made in the account.
How do I check if Zendesk is down right now?
Open Zendesk's status page and look at your own pod and the specific component you're using, not just the overall banner. A green headline can coexist with your instance being unavailable.
Zendesk works for one agent but not another. Is that an outage?
Almost never. One affected user points at a browser session, an extension, a permissions change or your SSO. Test a private window and a different network before escalating.
Tickets stopped arriving but Zendesk loads fine. What is that?
That's a mail flow problem, not an outage. Check your forwarding rules, your support address configuration and whether your email provider is having an incident of its own.
Should I open a ticket with Zendesk during an outage?
If the status page already shows the incident, no. Subscribe to it instead. Open one when your symptoms do not match anything published, and include your subdomain and timestamps.
Why does the queue explode when Zendesk comes back?
Because customers retried during the outage, often through a second channel, and everything queued upstream is delivered at once. Expect duplicate rates well above your normal.
The clean-up after the outage
Recovery delivers the same request three times from the same person. Ticket Merger folds those back together before your team wades in.
Start free trial14-day free trial. No credit card required.