Docs
Schedules & notifications
Cron jobs, standalone image jobs, and multi-channel alerts.
Schedules
Run shell or deploy jobs on a cron against applications, compose stacks, remote servers, or the Nixploy host. Enable, disable and run-now from the Schedules page; output is written to a run log with mode 0600, because it regularly includes connection strings.
Two ways to run
- exec — docker exec into a container that is already running. The service has to be up
- image — docker run a throwaway container from an image you name. The service can be stopped, which is what makes this a real standalone job: a nightly report, a migration, a cleanup that has no business keeping a container alive all day
An image job gets the environment's overlay network (so it reaches that environment's database by name), the merged organization → project → environment → service env over a 0600 env file rather than argv, and the same container hardening a deployment gets.
The job runs with sh as its entrypoint — without that override the image's own ENTRYPOINT would receive the command as arguments and silently ignore it. Exit 127 therefore means the image has no /bin/sh: scratch and distroless images cannot host a job. Run once executes the same container with no schedule row behind it, and still writes a run log and a deployment row.
Cron runs in the process timezone
Every cron expression — backups, schedules, the update checker, platform alerts — runs in the panel's timezone, which is UTC unless you set TZ. Changing TZ shifts every existing schedule, so decide at install time rather than after schedules exist. Ticks missed while the panel was down are warned about at boot and, with NIXPLOY_CRON_CATCH_UP=1, replayed once.
Notification channels
- Slack, Discord, Telegram, email
- Gotify, ntfy, Pushover, Mattermost, Lark, Teams
- Custom webhooks
- Events: deploy success/fail, backups, thresholds, service alerts, uptime flips, Docker cleanup, panel restarts
Also see the repository guides under docs/ · REST API reference