Automation
Scheduled cron tasks and service actions that belong inside app operations
Run cron jobs, post-deploy scripts, and service actions from the same platform workflow you use for releases and environments.
Routine application tasks should not depend on hidden server crontabs or scattered deployment scripts. Wodby brings cron jobs and service actions into a more visible operational model with logging, environment-aware configuration, and hooks that fit normal release workflows.
Schedule recurring jobs inside the application workflow
Cron tasks should be easy to define, change, and review without leaving the platform.
Wodby lets teams define cron jobs with familiar crontab syntax and execute commands inside the appropriate container context. That keeps recurring maintenance, data sync, and housekeeping work closer to the services that actually need it.
Start from stack-aware defaults and override by environment when needed
Operational jobs often vary across development, staging, and production.
Some services ship with useful default cron behavior at the stack level. Teams can keep those defaults, disable them, or override schedules for particular app instances when different environments need different task timing.
- Reuse sensible defaults where the stack already knows common tasks.
- Change schedules per environment when production and staging should behave differently.
- Avoid maintaining separate automation setups for the same application.
Review execution history, logs, and failures in one place
Scheduled automation is only trustworthy when teams can see what actually ran.
Wodby records cron execution history and surfaces failures so teams have a clearer operational trail. That reduces the guesswork around missed jobs, broken commands, or environment-specific issues that only appear after a deployment.
Run actions on platform events and post-deploy hooks
Not every automation task is time-based. Some belong to deployments, upgrades, or manual service operations.
Wodby actions cover routines triggered by events such as deployments or service upgrades. Teams can also define their own post-deploy scripts in the repository so migrations, cache invalidation, and similar tasks stay connected to the CI/CD workflow instead of living in a separate runbook.
Trigger routine actions directly from the UI when speed matters
Some maintenance tasks are easier when they are available as an intentional action button.
Services can expose UI-triggered actions for operational tasks such as clearing caches or running maintenance commands. That makes it easier for teams to execute safe, routine operations without hunting for the right command sequence first.
Next step
Make recurring and event-driven operations part of the platform
Bring cron schedules, deployment hooks, and service actions into a workflow your team can see, change, and reuse more confidently.