Docs
Crons, uptime and logs
Scheduled jobs run by powder, how uptime checks pick a URL and when they alert, and where to find deploy logs.
Scheduled jobs (crons)
Powder has an in-process scheduler that ticks every 60 seconds, runs the jobs that are due and records each result and its output in powder's own database. Each app's crons tab lists its jobs and their history.
- HTTP jobs call a URL on the app. They need a live custom domain, or a base domain on the server so that the default host exists.
- Each run has a 30 second timeout, and stored output is capped.
- Schedules are standard 5-field cron expressions.
Jobs that already live in a server's root crontab are shown for reference. Powder does not run them, but it reads each server's cron journal every 5 minutes and records when they fired, so their runs appear in the activity feed.
Uptime checks
Uptime checks are opt-in per app. When enabled, powder requests the app every 5 minutes with a 10 second timeout. The URL is the first of:
- the app's health URL, if set;
- the app's first live custom domain;
https://<container>.<base_domain>/, if the server has a base domain.
An app with none of these is skipped. A single failure does not alert: the app is marked down after 2 consecutive failures, and powder sends one notification on the up-to-down change.
Logs
- Deploy logs. Every deploy keeps its full output, streamed live while it runs. Open a deploy from the Deploys page. Failed deploys name the step that failed.
- Search. Each app's logs tab searches its deploy output and errors (at least 2 characters, filter by status, default window 30 days).
- Container logs. For a running app, read them on the server with
docker logs <container> --tail 100.
Deploy output can include environment banners, so keep the dashboard behind HTTPS.