Scheduled Tasks

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €24/mo; unlimited scheduled tasks, timezone support, logging

Generated from docs/plan/paid/scheduled-tasks/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merchants need to run recurring operations: generate daily sales summary email at 6 AM, run inventory forecast, send birthday discount emails. This feature provides a scheduler with timezone support, logging, and failure alerts.

The problem

I want to run tasks automatically on a schedule (daily sales report, weekly inventory check) but I have no way to schedule them without writing code or using an external service.

What it does

• Scheduled task entity: name, cron expression (or UI picker: daily/weekly/monthly + time), timezone, action (email template, webhook call, custom query export)
• Timezone support: schedule in merchant’s timezone (not UTC), account for DST
• Task history: log of each execution with timestamp, status, duration, output/result
• Failure handling: retry on failure (immediate, or exponential backoff), alert admin on repeated failures
• Action types: send email (to staff or customers), call webhook (POST JSON), export report to file and email, run query and email results
• UI: cron picker (user-friendly: daily at 6 AM, weekly on Monday at 9 AM, etc.), preview next 5 run dates, enable/disable toggle
• Execution guarantee: ‘at least once’ (task runs even if server briefly down; catches up when restarted), not ‘at most once’
• API endpoints: CRUD scheduled tasks, list executions, retry failed task

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• User-defined actions (custom JavaScript) — actions are predefined (email, webhook, export); no code execution
• Conditional scheduling (run only if stock < 10) — that is workflow-builder; scheduled-tasks is time-only, not event-triggered
• Task parallelism control — do not run two instances of the same task simultaneously (simple per-task mutex), but do not attempt distributed scheduling
• Scheduled task marketplace — users cannot share or import schedules from public sources

Data model

New entity: ScheduledTask {id, name, cron_expression, timezone, action_type (email/webhook/export), action_config (JSON), enabled, created_at, updated_at}. New entity: ScheduledTaskExecution {id, task_id, scheduled_at, started_at, completed_at, status (success/failed/running), result_summary, error_message (nullable)}. Schema migration across all three drivers.

API

• POST /api/scheduled-tasks — create task (admin only)
• GET /api/scheduled-tasks — list all tasks
• GET /api/scheduled-tasks/:id — fetch task detail
• PATCH /api/scheduled-tasks/:id — update task (admin only)
• DELETE /api/scheduled-tasks/:id — delete task (admin only)
• POST /api/scheduled-tasks/:id/test — run task immediately (dry-run or live)
• PATCH /api/scheduled-tasks/:id/enable — enable/disable task
• GET /api/scheduled-tasks/:id/executions — execution history (paginated)
• POST /api/scheduled-tasks/:id/executions/:execution_id/retry — manually retry failed execution

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Scheduled task manager: list of tasks with enable/disable toggle, next run time, last execution status. Create/edit task form: name, cron picker (visual: ‘daily at 6 AM’ or cron syntax), timezone dropdown, action type (email/webhook/export), action config (recipient email, webhook URL, or report template). Preview: show next 5 scheduled run dates. Execution history: table with run timestamp, status, duration, result (output preview or error message).

The seam — why this is paid

Core owns the scheduled task model, cron evaluation, action dispatch, and REST API. Paid layer owns high-availability scheduling (distributed scheduler across replicas, ensuring ‘at least once’ across node restarts), advanced actions (ML-based anomaly detection task, integration with external task queues), and support/uptime SLA.

Support commitment: task SLA (99.9% uptime), execution logging

Dependencies

• Cron library (assume available; e.g., node-cron, croner)
• Timezone library (assume available; e.g., date-fns-tz, moment-tz)
• Email system (already shipping in core) for email actions
• Scheduler/queue infrastructure (core must have a way to periodically evaluate due tasks)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A scheduled task can be created with a name, cron expression (‘0 6 * * *’ = daily at 6 AM), timezone, and action type
• The timezone picker shows ‘America/New_York’ and the task runs at 6 AM in that timezone (accounting for DST)
• Next run time is calculated correctly: if it is 10 AM Monday and task is ‘weekly on Wednesday 9 AM’, next run shows as Wednesday 9 AM
• When the scheduled time arrives, the task is executed; if the action is ‘send email’, the email is sent
• If a task fails (e.g., email provider down), it is retried immediately; if it fails again, retry_count increments
• After 3 retries, the task is marked failed and admin is alerted
• Execution history shows all runs with timestamp, status (success/failed), and duration
• A failed task can be manually retried via the ‘retry’ action; it runs immediately

Risks

Cron expression evaluation must be correct; wrong syntax silently does nothing (user thinks task runs but it doesn’t). Timezone handling is error-prone; DST transitions can shift run times. If the scheduler is down during a scheduled run, the task must catch up when the scheduler restarts (queue must be persistent). Runaway tasks (webhook calls forever) must timeout; long-running tasks block the scheduler. Duplicate execution must be prevented; if scheduler evaluates due tasks and crashes mid-execution, restart must not double-run.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.