A task that works when you press Enter has only passed its first test. The unattended version also needs an answer for slow inputs, partial results, repeated execution and yesterday's output remaining on screen.
This is a design checklist for small collection and reporting jobs. It describes decisions to make before scheduling. It does not claim a measured failure rate, a particular scheduler's reliability or that every implementation is already correct.
1. Write down what success means
“The process exited” is often too weak. A collection job may exit normally after reading a list page but fail to retrieve any usable details. Record separate counts for discovered items, accepted items, unchanged items and failed details.
Distinguish a successful check that found no new items from a check that could not reach its source. Showing an older result is useful if its timestamp and current check status remain visible.
2. Give each run a boundary
Choose limits for pages, items, request duration and total work. If a source unexpectedly grows or changes its navigation, the task should stop with an understandable result rather than continue indefinitely.
{
"started_at": "2026-11-01T08:00:00Z",
"status": "partial",
"checked": 12,
"stored": 3,
"unchanged": 8,
"failed": 1,
"next_action": "Retry the failed detail within its limit"
}The JSON above is an illustrative schema, not a result from a real run. Adapt the fields to the task you can actually observe.
3. Prevent accidental overlap
An hourly schedule does not imply a task always finishes in an hour. Decide whether a second invocation should wait, skip, or resume an incomplete run. A lock or lease needs a defined owner and recovery behavior; merely creating a permanent lock file can leave work stuck after a crash.
When tasks share a small server, staggering them may reduce overlap. Measure the effect rather than assuming a different start minute guarantees enough capacity.
4. Make retries bounded and meaningful
Retries need a limit and a rule for what to repeat. Reading a public page again differs from creating a payment or sending a message again. Before retrying a side effect, establish how the receiver identifies duplicates and what evidence shows the earlier attempt failed.
Keep credentials out of logs. Capture a status category and a useful reference to the failing step; do not dump complete request headers or private response bodies.
5. Leave a record you can use tomorrow
A small log should answer when the task last started, when it last completed successfully, which input range it covered and what remains to be checked. A single “healthy” indicator should not erase a partial failure.
Download the short checklist. Use it during a manual run, then test one known failure before enabling the schedule. That exercise is often more informative than adding another timer.
The next useful test
Try one source timing out, one invalid input and a second invocation while the first is still active. Keep those checks isolated from production side effects. Record the actual result and revise the workflow from what you observed.
For memory planning on a shared host, start with our VPS field notes and the browser-side budget calculator.