Scheduled Task and Cron Reliability

Runtime model

SophMate scheduled work depends on the site runtime, host cron behavior, provider availability, mail delivery, cache state, and the way WordPress processes background events. A workflow may be correct but still appear unreliable when visitor-triggered WP-Cron is delayed, a host throttles PHP, or a previous run leaves operators unsure what completed.

Reliability checks

Confirm whether the site uses visitor-triggered WP-Cron, server cron, queue workers, or host-managed background processing. Record expected run times, retry behavior, alert recipients, and what operators should inspect when a watcher is late. Pair this with cache queue and performance and watchers and alerts before expanding recurring workflows.

Failure response

Do not rerun scheduled tasks blindly. Review cron health, locks, host logs, provider status, mail delivery, audit records, and affected records first. Use diagnostics and support when the delay is reproducible or affects production users.

Quick reference

• Use this page when changing provider, budget, role, mail, queue, cron, source, cache, or WooCommerce context settings.
• Do not store secrets, credentials, purchase codes, or private customer data in documentation notes or screenshots.

Scope limits

• Do not rerun delayed scheduled work until locks, retries, duplicate risk, and affected records are understood.
• This page does not replace provider, host, mail, billing, security, or legal policy review where those owners are responsible.
• Use it to frame configuration decisions, not to store secrets or justify broad access.

Owner and cadence

• Primary owner: site administrator with provider, billing, and security responsibility.
• Review cadence: after provider, mailbox, role, budget, security, WooCommerce, or integration changes.
• Escalate when scheduled work is delayed, runs twice, skips alerts, or leaves operators unsure which workflow state is current.

Access and data boundary

• Restrict provider keys, billing, budgets, roles, mail routing, queues, cron, cache, and integration settings to accountable administrators.
• Document setting intent and validation results without storing API keys, mailbox passwords, purchase codes, raw logs, or private customer records.

Production checklist

• Record cron mode, expected schedule, retry behavior, alert recipients, and owner for each recurring SophMate workflow or watcher.
• Check locks, host logs, audit records, provider status, and mail delivery before rerunning delayed work.
• Document who owns provider credentials, budget limits, role access, notification routing, and ongoing review.
• Keep configuration changes behind administrator access and review them after plugin updates, staff changes, or incidents.

Acceptance checks

• Operators can tell whether scheduled work is delayed, running, completed, retried, or failed.
• Late or duplicate runs have a documented response path before production workflows scale.
• A second administrator can explain why each high-risk setting is enabled and who may change it.
• No production credential, support mailbox, or notification path depends on an unmanaged personal account.

Failure modes to test

• Test locked jobs, delayed queues, skipped cron runs, duplicate scheduled work, host throttling, and missed watcher alerts.
• Test invalid credentials, exhausted budget, unmonitored mailbox, wrong role mapping, queue delay, cron failure, and cache-dependent behavior.
• Confirm configuration failures are visible to an owner without exposing provider keys, mailbox credentials, or raw logs.

Evidence to capture

• Capture pause state, queued/running/scheduled work, last run, next run, owner, and restart criteria.
• Record changed setting, previous value category, new value category, owner, approval reason, and review date without storing secrets.
• Capture provider, budget, role, mailbox, queue, cron, cache, and WooCommerce evidence relevant to the setting being changed.

Decision record

• Decision field to include: expected schedule, queue or cron owner, lock handling, duplicate-prevention rule, and missed-alert response owner.
• Record the configuration decision, setting owner, previous setting category, new setting category, validation result, approval reason, and next review date.
• Include whether the change affects provider spend, privacy, mail delivery, queue or cron behavior, WooCommerce context, or user permissions.

Stop or rollback path

Pause scheduled or queued work when locks, delayed jobs, duplicate runs, or host throttling are unresolved. Resume only after queue state, cron timing, and affected records are reviewed.

Monitoring window

• Watch duplicate prevention, delayed jobs, retry count, queue depth, and affected-record state after throttling or scheduler issues.
• Monitor the next operating cycle for unexpected spend, blocked work, missed notifications, queue delays, or changed provider behavior.
• Compare the setting change against audit records, diagnostics, and user reports before making another related change.

Expansion criteria

• Widen the setting change only after audit records, user reports, diagnostics, and cost or delivery signals match expectations.
• The owner can explain how to reverse or narrow the change without searching through unrelated settings.

Common mistakes

• Rerunning delayed scheduled work before checking locks, retry state, audit records, and whether the original run is still completing.
• Using personal provider keys, personal mailboxes, or broad administrator access because it is faster during setup.
• Changing budgets, roles, notifications, or integrations without recording the owner and review reason.

Common questions

How do I know a delay is not an AI issue?

Review cron, queue depth, locks, host throttling, cache behavior, audit records, and provider status before treating delayed work as an assistant-quality problem.

Who should own this decision?

The site administrator should own the decision, with provider, billing, security, mail, or hosting owners involved when their systems are affected.

What should stop the rollout?

Stop when a setting changes spend, access, privacy, mail, queue, cron, cache, provider behavior, or WooCommerce behavior without validation evidence.

Related operations

• Pair configuration work with Roles and Permissions.
• Review Approval Controls before enabling write-capable modules.
• Use Cost Allocation and Client Billing Review before client or team billing reviews.
• Use Security and Key Rotation before changing provider credentials.
• Use Provider Models and Fallbacks before changing production model behavior.
• Use Data Residency and Provider Policy Review before sending sensitive context.
• Use Provider Rate Limits and Retry Planning before high-volume workflows.
• Use Source Freshness Review Calendar before teams depend on policy sources.