Client billing stops on Monday. Nobody notices until Thursday: the sync cron had failed four days — exit code 1 buried in an unread log. Alwaysdata ran the task; nobody watched.
Alwaysdata suits multi-language stacks with integrated crons. Scheduled task observability remains your duty once jobs touch money or data.
Minimal cron observability stack
| Layer | Tool | Role |
|---|---|---|
| Log file | logs/cron-sync-YYYY-MM-DD.log | Post-mortem debug |
| Exit code | set -e / trap ERR | Non-silent failure |
| Success ping | Healthchecks.io, Cronitor | Alert if missing |
| Alert | Email, Slack webhook | Human notified |
| Metric | Duration, rows processed | Slow drift |
Shell pattern:
#!/bin/bash
set -euo pipefail
LOG=~/logs/sync-$(date +%F).log
exec >>"$LOG" 2>&1
echo "START $(date -Is)"
php bin/sync.php
curl -fsS -m 10 --retry 3 https://hc-ping.com/your-uuid
echo "END $(date -Is)"
Common mistakes
Duplicate cron after migration without disabling old one.
Relative path — works in SSH, breaks in cron.
No lock — two concurrent instances corrupt data.
Infinite log — full disk, site down.
Timezone — panel UTC vs script Europe/Paris.
Shared hosting: limits and splitting
- Prefer jobs < few minutes; batch in chunks.
- Queue (Redis, DB) + short worker every minute.
- Test load after PHP/Node deploy.
The crux: silent success, silent failure
The first cron incident teaches what the panel never shows alone.
Decide and move forward without blind spots
- Cron inventory with owner and criticality.
- Logs + ping on critical jobs.
- Lock file against double exec.
- Monthly test deliberate failure → alert received?
- Alwaysdata profile + guides.
Frequently asked questions
Alwaysdata cron history?
Panel config + limited logs — instrument yourself.
Detect failure?
Dated logs, webhook, healthcheck ping at job end.
What to log?
Start/end, duration, exit code, volume — no secrets.
Long PHP cron?
Split; queue + worker if window exceeded.
If a cron touches billing or client data, no success ping = no prod.