Cron jobs
Four jobs declared in etc/crontab.xml. All run via Magento's standard default cron group — no special queue or worker setup needed. Make sure bin/magento cron:run is wired in your hosting (every minute, the standard).
byte8_preorder_send_ready_notifications
| Field | Value |
|---|---|
| Schedule | * * * * * (every minute) |
| Class | Cron/SendReadyNotifications.php |
The ready-notification drainer — implements the flag-and-drain pattern that keeps email delivery off the hot path.
markPreorderReady (called from admin actions, mass actions, the MSI plugin, and the scan-stock CLI) flips the pre-order to ready, ensures the completion token, and clears ready_notification_sent_at. It does not send the email inline. This cron picks up to 100 rows per tick matching:
status = 'ready'
AND total_remaining_amount > 0
AND ready_notification_sent_at IS NULL
AND ready_notification_attempts < 5
For each row it loads the canonical entity via the repository, calls NotificationSender::sendCompletionReadyNotification, and:
- On success — stamps
ready_notification_sent_atand clearsready_notification_last_error. - On failure — increments
ready_notification_attemptsand records the error inready_notification_last_error.
Per-row failures are isolated; one bad SMTP doesn't abort the batch. After 5 attempts the row is left alone — query ready_notification_last_error to investigate. Re-running Mark Ready (admin or CLI) resets the attempts counter for that row.
Why this exists: a bulk stock import that flips 50 SKUs into stock with 5 customers each = 250 emails. Sending them synchronously inside the admin save would hang the request and tie success to SMTP liveness. The drainer caps total latency to 60 seconds while keeping the admin save constant-time.
byte8_preorder_process_vault_captures
| Field | Value |
|---|---|
| Schedule | */5 * * * * (every 5 minutes) |
| Class | Cron/ProcessVaultCaptures.php |
Picks up pre-orders flagged vault_capture_status = pending and:
- Calls
VaultCaptureService::capture()for each one. - On success — moves to
complete, captures invoice, sends completion email. - On failure — increments attempts counter, reschedules at
now + retry_backoff × attempts. - When
attempts ≥ max_attempts— moves tofallback_sent, sends manual-pay email.
This job only runs when Vault Capture is enabled in config. Otherwise it short-circuits early.
For the deep-dive on what this does, see Vault capture deep-dive.
byte8_preorder_auto_complete
| Field | Value |
|---|---|
| Schedule | */15 * * * * (every 15 minutes) |
| Class | Cron/AutoCompletePreorders.php |
For pre-orders where the customer paid in full at checkout (no vault capture needed) and stock has arrived:
- Selects pre-orders with
status = readyandbalance_due = 0. - Marks them
complete. - Sends the completion email.
- Logs the auto-completion.
This is the cleanup pass for the "full payment" deposit mode — there's no vault capture involved, so we just need to flip the status when stock arrives.
byte8_preorder_expire
| Field | Value |
|---|---|
| Schedule | 0 2 * * * (daily at 2:00 AM) |
| Class | Cron/ExpirePreorders.php |
Cancels pre-orders that have been sitting in pending status for more than 30 days (configurable) without stock arriving:
- Selects pre-orders older than the threshold with status
pending/awaiting_stock. - Marks them
cancelled, reverts reservations. - Refunds the deposit if configured to.
- Sends the customer a cancellation email.
The 30-day default reflects most launch-window failures — if a drop slips by a month, the customer has likely lost interest and refunding now is better than chasing later. Adjust via config.
Configuration
The retry backoff and max attempts for vault captures live in Vault capture configuration.
The expiry threshold lives at:
| Field | Path | Default |
|---|---|---|
| Expire after (days) | byte8_preorder/expiry/days | 30 |
| Refund deposit on expiry | byte8_preorder/expiry/refund_deposit | Yes |
Monitoring
The Magento cron table (cron_schedule) shows each job execution with status (success, error, running). Use any standard cron monitoring (e.g. New Relic, Datadog Magento integration) — these jobs surface like every other Magento cron job.
For pre-order-specific monitoring:
# Show last 24h of vault capture results
bin/magento preorder:list --vault=succeeded --created-since=24h
bin/magento preorder:list --vault=failed --created-since=24h
Manual triggers
If you need to run a job out-of-band (without waiting for the schedule):
# Vault captures — see CLI page for full options
bin/magento preorder:vault:process
# Auto-complete — no dedicated CLI; trigger via cron:run
bin/magento cron:run --group=default
The expiry job has no manual CLI; it runs daily by design and shouldn't need ad-hoc invocation.
Related
- CLI commands — the manual equivalents.
- Vault capture deep-dive — the inner workings of the most important cron.
- Pre-order lifecycle — where these jobs fit.