WORDPRESS SCHEDULED TASKS

# Emails stuck on “Still waiting” in WordPress?

Check the saved entry, restore the site’s scheduled-task trigger and verify the notification’s actual result. Your host can help with the recurring scheduler.

[Follow the setup steps ↓](https://kibihq.com/#setup-steps)

Website enquiryVictoria · full home interior

ONE ENQUIRY. EVERYTHING BESIDE IT.

![Victoria’s demo enquiry, with Asha as owner and a call planned for tomorrow at 10am](https://kibihq.com/images/visuals/s03-rescheduled-desktop.webp)

AOwned byAsha

Next stepCall tomorrow, 10am

A real demo enquiry. The team planned the call.

CONNECT AND CHECK

## Follow the task, step by step.

- Open the entry in Kibi Forms’ Inbox, then find its “Still waiting” notification in Email log.

- Open a page of the affected site in your browser. Return to Email log and check whether the same notification progresses.

- If it still waits, ask your host to check scheduled-task health and whether DISABLE_WP_CRON is part of this site’s intended configuration.

- For a recurring fix, have the host configure its supported scheduler to request your own site’s wp-cron.php every five minutes, checking any existing scheduler first.

- Verify the task actually runs, then inspect Email log. Follow a new sending error if one appears; for Sent, check the recipient inbox and spam. Resend failed notifications after their cause is resolved.

First, read the status

## Waiting is a different problem from a failed send

Kibi Forms can send emails through WordPress's scheduled tasks. In Email log, a notification that remains pending for more than thirty minutes is shown as “Still waiting”, with a message that scheduled tasks do not seem to be running. This points to a task that has not progressed, rather than proof that the mail server rejected a message. Start with the state actually shown before changing the site's email credentials.

Check the entry in the WordPress Inbox while you investigate. Kibi Forms saves the submitted entry before email delivery is attempted, so a waiting notification does not require the visitor to submit again to make the existing request visible. Keep the site's normal backup process in place and assign someone to review saved entries. Queue troubleshooting should not leave the customer's enquiry without a person responsible for its next action.

ILLUSTRATIVE EXAMPLE

### Fictional example

The studio’s demo enquiry is visible in the Inbox, but its email remains “Still waiting”. The administrator checks scheduling while the receptionist can still read the saved request.

Prepare the check

## Identify who manages the site and hosting

Have an administrator login for the affected WordPress site. If a recurring fix is needed, involve the person who can manage its hosting control panel or scheduled tasks. Record the site and notification time you are checking so everyone investigates the same environment. A task configured for a staging copy does not establish that the production site's waiting emails are being processed.

Ask whether the host already manages WordPress scheduled tasks. Managed hosting can supply its own process, and the control-panel labels vary. Review the existing arrangement before adding another scheduler or editing a configuration file. The person making the change should understand how to restore the prior settings. Keep hosting passwords, access keys and configuration files out of the general support discussion; share the task and observations instead.

- Confirm the affected production site.

- Identify the administrator and hosting contact.

- Check whether scheduling is already managed by the host.

- Keep a record of the notification time and visible state.

First recovery check

## Open the site and watch the same notification

[Fix a reported WordPress email failure](https://kibihq.com/help/wordpress-email)

Open a page of the affected site in a browser, then return to Kibi Forms' Email log and review the waiting notification. WordPress normally checks scheduled tasks in response to page visits rather than running them continuously. On a quiet site, a visit can help due work proceed. Watch for a state change and inspect the result; do not treat the act of opening the page as proof that every queued job completed.

If the notification moves to Sent, check the intended recipient's inbox and spam folder. If it moves to a sending failure, use the error and the WordPress email guide for that next problem. If it remains waiting, continue with the scheduled-task checks. Record this first result before making other changes, because it tells the host whether a normal page visit was enough to advance the pending work.

Ask the host

## Check the current scheduled-task configuration

If notifications keep waiting, ask your host whether WordPress scheduled tasks are disabled or prevented from running. The configuration can include DISABLE_WP_CRON in wp-config.php; have an authorised administrator inspect it in context. Do not remove or change a setting blindly, because the site may already rely on a server scheduler. The useful question is how this site is supposed to run due WordPress work and whether that mechanism is functioning.

Give the host a concrete observation: the relevant time, the state shown in Email log and whether visiting the site advanced it. Avoid sending an entire configuration file, which may contain database credentials and other secrets. If the host reports another scheduling or request problem, follow its site-specific instructions. A guessed change to an unrelated plugin or an SMTP password will not establish why the pending task did not run.

ILLUSTRATIVE EXAMPLE

### Useful support request

“A notification from our fictional test is still waiting. We opened the affected site and checked the log again. Can you verify how this site runs its scheduled WordPress tasks?” Include the time, with private values hidden.

Recurring fix

## Use the host’s supported task scheduler

[WordPress system-scheduler guidance](https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/)

For a site that needs predictable task triggering, ask the host to configure its system scheduler for WordPress. The product setup brief recommends opening the site's own wp-cron.php every five minutes. The domain must be your actual site, not a URL copied from an example. Follow the host's supported method and confirm the exact address, interval and existing scheduler arrangement before the administrator saves the change.

WordPress documents connecting WP-Cron to a system task scheduler. Its instructions also discuss the relationship with page-triggered scheduling; have the host apply that guidance to the environment rather than pasting a generic command. A scheduler provides a regular trigger, but task processing and later email delivery can still fail for other reasons. Verify its effect in Kibi Forms instead of promising that every message will now arrive at an exact time.

Check the scheduler

## Verify execution, not just a saved job

[WP Crontrol on WordPress.org](https://wordpress.org/plugins/wp-crontrol/)

After configuration, ask the host to confirm that the scheduled task actually runs against the intended site. A control-panel entry can be saved with an incorrect address or a command that never completes. Use the host's execution history or supported diagnostic method rather than assuming that a five-minute interval in a form proves successful execution. Note when the first verified run occurred so you can compare it with the waiting notification.

The WP Crontrol plugin can help an authorised administrator inspect WordPress scheduled events when that is appropriate for the site. Use it to understand task state under the host's guidance, not to delete unfamiliar events until the warning disappears. Other WordPress features may depend on those events. Keep the inspection focused on why the due work is waiting, and leave the business's existing scheduled publishing, updates and other tasks under their normal ownership.

Expected result

## Watch pending work progress and test the form again

Return to Kibi Forms' Email log and inspect the same waiting notification after scheduled tasks are running. It should progress to an actual result. If it reports a sending failure, read the reason and follow the email guide; the scheduler has exposed a different problem that still needs repair. If it shows Sent, check the recipient mailbox. A completed queue attempt and a message observed in the inbox remain separate pieces of evidence.

Send a fresh fictional submission from the public form and confirm that the entry is saved and its notification progresses. Check the visitor's confirmation too. This establishes how the current form behaves after the change, while the older log item shows what happened to the waiting work. Use a recognisable test phrase and avoid repeated real-customer submissions. Record the outcome so a teammate can tell that the scheduler and notification checks were both completed.

- Existing waiting item has a new observed result.

- Fresh public submission is saved.

- Notification progresses beyond waiting.

- Recipient inbox or spam is checked when sending succeeds.

After recovery

## Resend only the notifications that need it

[WordPress email guide](https://kibihq.com/help/wordpress-email)[Connect your existing form](https://kibihq.com/help/connect-website-form)

When a notification has genuinely failed and the cause is resolved, use its Resend action in Email log and inspect the new attempt. Do not repeatedly resend while the task is still waiting or its previous result is unclear. If the site reports an interrupted send, check the mail-service outcome before adding another copy. The administrator should understand whether they are recovering a pending task or creating a new email attempt.

Leave a short maintenance note naming the affected site, scheduler owner, intended interval and last successful test. Exclude hosting credentials and configuration contents. Recheck after a hosting move, scheduler change or extended waiting warning. Meanwhile, keep the business process independent of the notification: someone should still review the saved enquiries and decide the next action. Kibi Forms' local entry and email tools remain available without connecting to the paid Kibi CRM.

THE PRACTICAL QUESTIONS

## Decide with the details.

Will opening the site always fix waiting emails?

It can trigger WordPress’s normal scheduled-task check, but it is not a guarantee. Inspect the same log item afterward. If waiting continues, ask the host to check the site’s configured scheduling process.

Does a system scheduler guarantee inbox arrival?

No. It helps due WordPress tasks run. A task can then report a sending error, and even Sent does not prove inbox delivery. Check the sending result and the recipient mailbox separately.

Source: https://kibihq.com/help/wordpress-cron/