After migration: prove scheduled work runs and email arrives

Choose one harmless end-to-end task

Start with a nonproduction account and an owned test inbox. Choose a benign scheduled notification and a password-reset test that cannot affect an actual learner. Record the environment, plugin version, timezone, intended recipient, and who will judge the result. Do not use a live renewal, payment retry, or real student record as a fixture.

This is a documentation-based acceptance plan with a fictional worked record. We have not run these WordPress or hosting-provider tests. The CSV distinguishes example outcomes from empty fields for your own evidence; copying an example result does not make a migration pass.

Identify which scheduler actually owns the work

WordPress documents that WP-Cron checks scheduled work on page loads. A low-traffic site may therefore run a due event later than its planned time. WordPress also documents connecting WP-Cron to a system task scheduler. Neither fact establishes how a specific membership reminder, gateway renewal, or course plugin is invoked.

First identify the actual event and scheduler from the relevant plugin documentation and configuration. Confirm that only the intended environment will invoke it. If a system scheduler is used, retain its invocation time and the application execution evidence separately. A scheduler process exiting successfully is not proof that the intended event ran.

Work through the fictional record

Assume a test reminder is scheduled for 09:00 UTC on September 15, 2026. The example allows two minutes for execution and five minutes for inbox arrival. These are invented acceptance limits for this exercise, not WordPress or hosting service guarantees.

In the worked example, invocation occurs at 09:00:20, execution at 09:00:22, and the test message reaches the inbox at 09:01:10. Its link opens the intended test host, where the test account completes the harmless reminder acknowledgement and sees the saved acknowledgement state. A later replay produces no duplicate. Those fictional observations meet the example limits. A second example receives a provider acceptance response but has no inbox receipt at 09:05:00; delivery remains unresolved and the row cannot pass.

Keep mailbox hosting separate from site email

Kinsta distinguishes mailbox hosting from transactional email generated by the website, documents transactional support on production and staging, and applies daily limits. Read the current provider-specific limits before a test. Preserving incoming-mail MX records alone does not prove that password resets or enrollment messages still arrive.

For a failed row, inspect the actual sender configuration, relevant DNS authentication, provider logs, and owned inbox before changing hosts or increasing a plan. Save only redacted evidence references in a shared worksheet; do not put reset URLs, tokens, email addresses, or message contents into a public download.

Use the kit as an acceptance record

• Keep the fictional rows as examples; enter real evidence only in the operator columns or a separate copy.
• Define your own timing limits before running a test and record its timezone.
• Test the actual link destination and user action after receipt.
• Record duplicate checks and unresolved failures instead of turning missing evidence into a pass.
• Use a separate low-traffic test to challenge page-load scheduling assumptions.

Sources & verification

Product details and prices can change. Check the linked provider before buying.

1. WordPress: Cron and page-load scheduling Accessed 2026-09-14
2. WordPress: connect WP-Cron to a system task scheduler Accessed 2026-09-14
3. Kinsta: email hosting and transactional email Accessed 2026-09-14