How to use Zendesk automation conditions since status change

If you're managing a busy support queue, you've probably faced this scenario: a customer hasn't replied to your follow-up in days, and that ticket is just sitting there, cluttering your view. Or maybe you need to nudge a teammate about a ticket that's been open too long. This is exactly where Zendesk's automation conditions come in handy.

The thing is, there's a common point of confusion. Many people search for "Zendesk trigger condition hours since status change" when what they actually need is an automation, not a trigger. Triggers and automations serve completely different purposes in Zendesk, and understanding the distinction is key to building workflows that actually work.

In this guide, we'll walk through how to use time-based conditions in Zendesk automations. You'll learn what conditions are available, how to set them up correctly, and the best practices that prevent headaches down the road. We'll also look at how our AI tools at eesel AI can complement these automations to create a more intelligent support workflow.

Understanding triggers vs. automations in Zendesk

Let's clear up the confusion. Triggers and automations are both automation tools in Zendesk, but they work on completely different timelines.

Triggers are event-based. They fire the instant something happens to a ticket. When a ticket is created, updated, or changed in any way, triggers evaluate their conditions immediately and act within seconds. If a customer submits a ticket with the word "urgent" in the subject, a trigger can immediately assign it to your priority queue and notify a senior agent. There's no delay.

Automations are time-based. They run on a schedule, typically once per hour, and check for conditions that involve the passage of time. This is where "hours since" conditions live. Automations are perfect for those "follow up after X days" scenarios that triggers simply can't handle.

Here's the short version: if you need something to happen immediately based on a ticket event, use a trigger. If you need something to happen after a certain amount of time has passed, use an automation with "hours since" conditions.

The "hours since" conditions are only available in automations because they fundamentally require time to pass. A trigger can't know how many hours have elapsed since a status change because triggers only look at the current state of a ticket at the moment it changes.

While Zendesk's native automation handles time-based actions well, some teams find they need more intelligent routing before those time-based rules kick in. That's where eesel AI can help. AI Triage works alongside your setup by handling the initial categorization and routing, letting your automations focus on timing-based follow-ups.

Available "hours since" conditions in Zendesk

Zendesk offers a comprehensive set of time-based conditions you can use in automations. Here's what's available:

Status-based conditions:

• Hours since created
• Hours since open
• Hours since pending
• Hours since on-hold
• Hours since solved
• Hours since status category [category name]

Assignment and update conditions:

• Hours since assigned
• Hours since update
• Hours since requester update
• Hours since assignee update

Task and SLA conditions:

• Hours since due date (for task tickets)
• Hours until due date
• Hours since last SLA breach
• Hours until next SLA breach

One important note: there is no "hours since closed" condition. Once a ticket is closed, it cannot be modified by automations, so this condition wouldn't serve any purpose.

Business hours vs. calendar hours

If you're on a Professional or Enterprise plan, you can configure business hours and holidays in your Zendesk account. This gives you an important choice when setting up time-based conditions.

Calendar hours count every hour that passes, 24/7. If you set an automation to act after 48 hours, it will fire exactly 48 hours later regardless of weekends or holidays.

Business hours only count the hours within your defined business schedule. If your support team works 9 AM to 5 PM on weekdays, and you set an automation for 24 business hours, it won't fire until three business days have passed.

Which should you use? It depends on your support model. If you promise customers a response within business hours, use business hours for your SLAs and escalation automations. For general housekeeping like closing old tickets, calendar hours usually make more sense.

How Zendesk counts hours

Understanding the automation cycle helps explain the quirks you'll encounter. Automations run approximately once per hour, but not necessarily at the top of the hour. The first time an automation runs after conditions are met counts as "zero" hours. Each subsequent hourly run counts as one additional hour.

This means if a ticket becomes pending at 9:15 AM and your automation runs at 9:47 AM (32 minutes later), that first run counts as hour zero. The next run at 10:47 AM counts as hour one, and so on. You can only specify whole hours in conditions, not fractions, so setting "hours since pending is 1" requires at least one full hour to have passed since that first automation run.

Step-by-step: Creating your first automation

Let's walk through creating a practical automation that solves pending tickets after customers haven't responded for 48 hours. This is one of the most common use cases for time-based conditions.

Step 1: Navigate to Admin Center > Objects and rules > Business rules > Automations

Start by opening your Zendesk Admin Center. Under "Objects and rules," find "Business rules" and then click on "Automations." This shows you a list of all existing automations in your account, including any default ones Zendesk has created.

Step 2: Add your conditions

Click "Add automation" to create a new one. You'll see two sections: "Meet all of the following conditions" and "Perform these actions." In the conditions section, start building your rule.

For our auto-solve example, add these conditions:

• Ticket: Status category | Is | Pending
• Ticket: Hours since status category pending | Greater than | 48
• Ticket: Tags | Contains none of the following | auto_solved

The status condition ensures we only look at pending tickets. The hours condition sets our 48-hour threshold. The tag condition is our nullifier, ensuring this automation only runs once per ticket.

Step 3: Configure the "hours since" condition

When you select a "hours since" condition, you'll choose from a dropdown of options like "Hours since pending" or "Hours since solved." Then you select an operator: "Is," "Greater than," or "Less than."

Here's the key tip: use "Greater than" whenever you can instead of "Is." Because automations run hourly, an "Is 24" condition only evaluates to true during the brief window when the ticket has been in that state for exactly 24 hours. If the automation runs at 23.5 hours and then again at 24.5 hours, it misses that exact window. "Greater than 24" catches all tickets that have exceeded 24 hours, giving you a much wider window for the automation to fire.

Step 4: Add nullifying conditions

The nullifying condition is what prevents your automation from running repeatedly on the same ticket. Without it, a ticket that meets "Hours since pending greater than 48" would trigger the automation every single hour it remains pending.

The standard pattern is:

1. Check that a specific tag is NOT present (e.g., "Contains none of the following: auto_solved")
2. Add that same tag as an action when the automation fires

Once the tag is added, the ticket no longer meets the conditions, so the automation won't fire again.

Step 5: Define actions and save

In the "Perform these actions" section, add what you want to happen:

• Ticket: Add tags | auto_solved
• Ticket: Status category | Solved
• Notifications: User email | (requester and CCs) | [Your custom message]

The notification is optional but recommended. Letting customers know their ticket was automatically resolved (and that they can reply to reopen it) provides a better experience than silently closing tickets.

Click "Create automation" and you're done. The automation will start running on its next hourly cycle.

Critical best practices for Zendesk automation conditions since status change

After setting up hundreds of automations, experienced Zendesk admins have learned a few lessons the hard way. Here's what to watch out for.

Use "Greater than" not "Is"

This is the most common mistake with time-based conditions. When you use "Hours since solved is 24," you're asking Zendesk to catch that ticket at exactly the 24-hour mark. But because automations run hourly (and not always at predictable times), that exact window is easy to miss.

If the automation runs at 23.5 hours, the condition isn't met. If it then runs at 24.5 hours, the "is 24" condition is no longer true. The ticket will never trigger the automation.

"Greater than 24" solves this. It evaluates to true for any ticket that's been solved for 24 hours or more, giving your automation a wide window to catch it on the next hourly run.

Always include nullifying conditions

Without a nullifying condition, your automation will run repeatedly on the same ticket. Imagine an automation that adds a tag and notifies a manager when "Hours since open greater than 8." Without a nullifier, that manager gets notified every single hour until the ticket status changes.

The tag pattern (check for absence, then add as action) is the most reliable nullifier. Tags persist on tickets even when status changes, so your automation only runs once.

Understanding the 1000 ticket limit

Zendesk automations can only process 1000 tickets per automation cycle. If you have more than 1000 tickets meeting your conditions, the remaining tickets wait for the next hourly cycle.

This rarely affects small teams, but large support operations should keep this in mind. The 1000-ticket limit is per automation, not per account, so having multiple automations can help distribute the load.

Business hours vs. calendar hours

Be explicit about which you're using. If you set "Hours since pending greater than 24" and you're using business hours, that actually means three 8-hour business days, not one calendar day. This can confuse both agents and customers if expectations aren't aligned.

Document which automations use business hours vs. calendar hours, particularly if you have different schedules for different brands or teams.

Common use cases for "hours since" conditions

Time-based automations are incredibly versatile. Here are the most common ways support teams use them:

Auto-solving pending tickets. When you've asked a customer for information and they don't respond, automatically solve the ticket after 48-72 hours. This keeps your queue clean while allowing customers to reopen by replying.

Sending reminder emails. Before auto-solving, send a friendly reminder at 24 hours: "Just checking in to see if you still need help with this. We'll automatically close this ticket in 24 hours if we don't hear back."

Escalating stale tickets. If a ticket sits open (not pending) for 4-8 hours depending on priority, automatically bump it to a senior agent or notify a manager. This ensures nothing falls through the cracks.

Closing solved tickets. Zendesk's default automation closes solved tickets after 96 hours. You can customize this timing or add additional actions like sending satisfaction surveys before closure.

Following up on on-hold tickets. When you're waiting for a third party, tickets often get forgotten. Set an automation to notify the assignee after 48 hours of on-hold status.

SLA breach warnings. Use "Hours until next SLA breach" conditions to send warnings to agents when tickets are approaching their SLA limits, giving them time to respond before breaching.

Troubleshooting when automations don't work

When an automation isn't working as expected, here's how to diagnose the issue:

Check if conditions are actually met. Open a ticket that should have triggered the automation and verify every condition manually. Is the status what you expect? Has enough time actually passed? Are there tags present that might be blocking it?

Verify nullifying conditions aren't blocking execution. If you added a nullifying tag but the automation never ran, check if that tag was added through some other means (another automation, a trigger, or manually).

Check automation run history. Zendesk keeps a log of automation activity in the automation revision history. You can see which automations ran, when they ran, and how many tickets they processed. This helps identify if the automation is running but not finding matching tickets.

Watch out for common mistakes:

• Closed tickets cannot be updated by automations. If your conditions would match a closed ticket, the automation simply won't act on it.
• Decimal hours aren't supported. If you set "Hours since pending is 1.5," Zendesk interprets this as 1 hour.
• Time-based conditions can't be used in "Meet any of these conditions" sections. They must be in "Meet all of the following conditions."

Enhancing Zendesk workflows with eesel AI

Zendesk's native automations are powerful for time-based actions, but they work best when tickets are already properly categorized and routed. That's where we can help.

eesel AI integrates directly with Zendesk to handle the intelligence layer before your automations kick in. Instead of relying solely on time-based rules, the AI Agent can analyze ticket intent, sentiment, and urgency to make smart routing decisions immediately.

Here's how it works together: eesel AI reads incoming tickets and routes them to the right team based on what the customer actually needs. Then your time-based automations handle the follow-ups, reminders, and escalations according to your schedule. The result is a workflow where tickets reach the right people faster, and your automations handle the timing.

For example, instead of just escalating any ticket that's been open for 4 hours, you could have eesel AI Triage identify high-priority issues immediately and route them to senior agents, while your automations handle the standard follow-up sequences for everything else.

Start automating your Zendesk workflow today

Setting up Zendesk automation conditions since status change is one of the most effective ways to keep your support queue manageable. The key is understanding the difference between triggers and automations, using "Greater than" instead of "Is" for time conditions, and always including nullifying conditions to prevent repeated actions.

Start simple. A basic automation that solves pending tickets after 48 hours of inactivity provides immediate value and keeps your queue clean. Once you're comfortable with the mechanics, you can build more sophisticated workflows with multiple conditions and actions.

If you find yourself needing more intelligent automation than time-based rules can provide, eesel AI works alongside Zendesk to handle the nuanced routing and categorization that rule-based triggers struggle with. See how eesel AI can enhance your Zendesk setup.