How to automatically close inactive support tickets in WordPress

Decide what counts as inactivity before changing any settings. In most support workflows, the clock should start after the latest customer or agent reply, not when the ticket was created.

Choose a sensible period, such as 7, 14, or 30 days, and identify statuses that are waiting for the customer. Do not include statuses such as Escalated, Waiting for vendor, or Under investigation unless your team has agreed that they may be closed automatically.

Open your ticketing plugin’s settings and look for an option named something like automatic close, inactive tickets, ticket ageing, or workflow automation. WordPress core has no setting that can close arbitrary support tickets, so the option must come from the helpdesk system or custom development.

If your helpdesk already supports inactivity rules, use that native feature instead of adding a second automation. Multiple rules can close the same ticket or send duplicate messages.

Set the rule to check only the selected ticket statuses, use the last activity date, and change qualifying tickets to a dedicated closed status. Add a closing note or customer message explaining that the ticket was closed because no reply was received.

This route is fine when your helpdesk provides these controls. If it does not, there is no dependable WordPress-only switch to add them. You would need custom code that queries the helpdesk’s ticket data and runs on a scheduled task, and that code must use the helpdesk’s documented API or data model.

Send at least one warning before closure, for example three days before the deadline. Tell the customer how long they have to reply and whether replying will reopen the ticket or require a new request.

Use the ticket system’s own notification templates so the message includes the correct ticket reference. Test delivery with a real customer account, because a saved template does not prove that mail is reaching inboxes.

Automatic closure normally depends on a scheduled task. WordPress Cron checks scheduled work during page loads, so a quiet site, blocked loopback request, or disabled Cron can delay closures. WordPress’s documentation notes that a task due at 2:00pm may not run until the next page load.

Check the scheduled-task log after saving the rule. On a low-traffic or business-critical site, ask your host to run a real server scheduler that triggers WordPress Cron. If custom code is used, schedule the event only once with wp_next_scheduled(); repeatedly scheduling it can create duplicate jobs.

Create test tickets with each relevant status and arrange for their last activity dates to pass the rule, or use the helpdesk’s test or manual-run facility. Confirm that an excluded status stays open, a warning is sent at the right time, and a customer reply prevents closure where that behaviour is supported.

Review the first batch of automatically closed tickets the next working day. The common Friday failure is a rule aimed at every open ticket, which closes cases waiting on your team rather than cases waiting on the customer.

If your helpdesk lacks native inactivity automation, SupportCandy’s Automatic Close Tickets add-on is a direct way to add it. In SupportCandy, go to Support → Settings → Automatic Close Tickets, select the ticket statuses to check, set the inactive age in days, and choose the close status.

For advance warnings, go to Support → Email Notifications → Automatic Close Tickets and create templates for the chosen number of days before closing. A customer reply removes the ticket from automatic closing, according to the add-on documentation.