When a scheduled task produces no output, do not immediately delete it or repeatedly click rerun. “No results” can mean at least four things: the task was never triggered, it encountered an error after being triggered, it completed successfully but produced empty output, or the output exists but the notification was not delivered. Classify the issue first, then follow the evidence. This is usually faster than rebuilding the task and avoids losing evidence from the incident.
Preserve the evidence first: Collect four pieces of information
Record the task ID, expected run time and its time zone, the most recent successful run time, and the final status of this run. Screenshots can provide supporting context, but copyable run IDs and timestamps are what really matter.
If there is no record at all in the run list, inspect the scheduling layer. If there is a start time and an error, inspect the execution layer. If the status is successful but the count is zero, inspect the inputs and acceptance criteria. If a file exists but no message was received, inspect the notification pipeline separately.
- Pause automatic retries to prevent duplicate writes
- Copy the error summary and the last successful step
- Confirm that you are viewing this run rather than an older output
Layer 1: Trigger time and enabled status
Confirm that the task has not been paused and that the schedule expression matches the next run time shown in the interface. A natural-language time such as “8:00 a.m.” must be tied to a time zone. Server time, account time, and business time may differ.
Move the next test to a few minutes from now and use a read-only task to verify it. Do not wait until the next day just to test it, and do not change other parameters in the original task first, or you will not know which setting made the difference.
- Verify the day-of-week, date, and month fields
- Check for daylight saving time or time zone changes
- See whether the scheduler created a run record
Layers 2–4: Inputs, permissions, and the execution environment
Read the inputs using the same identity as the scheduled task. A file may exist without being readable, and an API response with status 200 may still be a login page or an empty array. Check the content type, record count, and update time to avoid treating empty input as a success.
Next, verify whether the credentials have expired, whether the task identity has the required permissions for the target path, and whether the network egress can reach dependent services. Distinguish a connection timeout from exceeding the task’s total runtime limit, because they require different fixes.
- Confirm that the input is not an empty file or stale cache
- Verify minimum read and write permissions
- Record external API status codes and response types
- Set limited retries and an overall timeout
Layers 5–6: Output and notifications
A process returning 0 or a status of completed only means that the executor did not report an error. Open the final file or page and verify the key fields, item count, and timestamp for this run. The output path should be absolute, and the name should ideally include a unique run key.
Notifications use a separate pipeline. First, use a fixed test message to verify recipients, channel permissions, and filtering rules. Do not rerun the main task to test notifications, because doing so may publish the same content again or create duplicate database writes.
- Verify that the output exists and can be opened
- Check the result count and run time
- Send a test notification separately
Post-fix verification and prevention
Complete an end-to-end test: create a run record, read non-empty input, generate a new output, and send a notification containing the output location. Wait for the next normal cycle before disabling temporary logging.
Save the start time, end time, input count, output count, and error summary for every run. Create separate alerts for “no runs for an extended period” and “consecutive empty results.” The former is usually a scheduling issue, while the latter is more likely to involve data or permissions.
- Use the date plus the task name as an idempotency key
- Set an anomaly threshold for empty results
- Send reminders before credentials expire
- Retain the most recent successful status
Further reading
To review related areas, read Workflow monitoring and error recovery and WordPress internal link troubleshooting process.
Next step
If the task needs to run unattended, first create a read-only test task in SmaugBrain and incorporate the six layers above into its acceptance criteria.