Skip to main content

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

FieldValue
Schedule* * * * * (every minute)
ClassCron/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_at and clears ready_notification_last_error.
  • On failure — increments ready_notification_attempts and records the error in ready_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

FieldValue
Schedule*/5 * * * * (every 5 minutes)
ClassCron/ProcessVaultCaptures.php

Picks up pre-orders flagged vault_capture_status = pending and:

  1. Calls VaultCaptureService::capture() for each one.
  2. On success — moves to complete, captures invoice, sends completion email.
  3. On failure — increments attempts counter, reschedules at now + retry_backoff × attempts.
  4. When attempts ≥ max_attempts — moves to fallback_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

FieldValue
Schedule*/15 * * * * (every 15 minutes)
ClassCron/AutoCompletePreorders.php

For pre-orders where the customer paid in full at checkout (no vault capture needed) and stock has arrived:

  1. Selects pre-orders with status = ready and balance_due = 0.
  2. Marks them complete.
  3. Sends the completion email.
  4. 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

FieldValue
Schedule0 2 * * * (daily at 2:00 AM)
ClassCron/ExpirePreorders.php

Cancels pre-orders that have been sitting in pending status for more than 30 days (configurable) without stock arriving:

  1. Selects pre-orders older than the threshold with status pending / awaiting_stock.
  2. Marks them cancelled, reverts reservations.
  3. Refunds the deposit if configured to.
  4. 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:

FieldPathDefault
Expire after (days)byte8_preorder/expiry/days30
Refund deposit on expirybyte8_preorder/expiry/refund_depositYes

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.