Most automations react to something happening: a customer replies, a ticket is created, a status changes. Support work also needs the opposite — automations that react to something not happening. A ticket has sat solved for four days and nobody objected. A ticket has gone twenty-four hours with no reply from your team. A customer was asked a question a week ago and never answered.
The Ticket Time Sweep trigger covers exactly that case. Once an hour, DevStride walks every open ticket in your Service Desk, works out how long it has been since each of a handful of moments, and runs your automation on the tickets that match.
When you enable Service Desk, DevStride creates one Ticket Time Sweep automation for you:
Close tickets that have been Solved for 4 days. When it closes a ticket, the requester is emailed to let them know.
This is the "did we actually finish?" safety net most desks end up building by hand. A ticket is marked Solved, the customer gets a few days to come back and say "actually, it's still broken" — and if they don't, the ticket closes itself and the customer is told.
You'll find it on the Automate Workflows page like any other automation. It is yours to edit: open it and change the 4-day threshold, add conditions, change the action, pause it, or delete it outright. Nothing recreates an automation you deliberately delete.
The automation is only switched on automatically for a brand-new Service Desk — one with no tickets yet. A desk that already has a ticket history gets it paused, with a note asking an admin to review it first.
That's deliberate, and it's the whole reason the rule exists: a desk with a long back catalogue of Solved tickets would otherwise close all of them at once, and email every one of those customers, the moment the automation started running. So if your Service Desk predates this release — or you simply turn Service Desk off and on again — read the conditions, decide you're happy with them, and then enable it.
Create it like any other automation (see Setting Up Basic Automations), and pick Ticket Time Sweep under the Service Desk trigger category.
Four elapsed-time conditions are available on this trigger, each answering "how long since…":
| Condition | Measures from |
|---|---|
| Hours Since Created | When the ticket was raised. |
| Hours Since Status Changed | When the ticket last moved to its current status. (For a ticket that has never moved, this is its creation time — so the clock always runs.) |
| Hours Since Staff Reply | Your team's last public reply to the customer. Internal notes don't count — the customer never saw them. |
| Hours Since Customer Reply | The customer's last reply. |
Each takes is at least or is less than, a number of hours, and one more choice that matters more than it looks:
You can combine these with the ordinary ticket conditions — Customer Status, priority, team, assignee, work type, tags, and so on — to scope a rule precisely.
First-response escalation. Hours Since Staff Reply is at least 8 (business hours) and Customer Status is equal to Open → Send Notification to the support team. Nobody has answered this customer in a working day.
No-reply nudge. Hours Since Staff Reply is less than 1 and Hours Since Customer Reply is at least 168 (calendar) → Send Customer Reply: "We're still waiting to hear back — let us know if you'd like us to keep this open." You answered; they went quiet.
Faster auto-close for a low-touch queue. Duplicate the seeded auto-close automation, add a Work Type condition, and drop the threshold to 24 hours for the queue where a solved ticket is very unlikely to come back.
Each automation can fire at most once per ticket per day, so a rule that keeps matching — a first-response escalation on a ticket that stays unanswered — nudges once a day rather than once an hour.
An escalation that measures "no reply in 8 hours" against wall-clock time will fire at 3am on a Sunday for a ticket that arrived at 7pm on Saturday. That's why the Business hours option exists — it counts only the hours your team is open, so eight business hours after a Friday afternoon ticket is Monday morning, not the weekend.
Business hours come from a Schedule — the same schedules SLA policies use. Set them up in Settings → Service Desk → Schedules (Service Level Agreements covers them in full).
When an automation asks for business hours, DevStride works out which calendar to use, per ticket, in this order:
Service Level Agreements (SLA)
Promise how fast your team responds to and resolves tickets, have DevStride track the clock against your real business hours, and get warned automatically before a promise is missed.
My Work
My Work is your personal, cross-project view of the items that are yours — choose what to show, work items in place, and shape and save the view to fit how you work.