You have an API sync script — hotels, products, orders or rates — and you need it to run on its own. Should you schedule it with a cron job, or keep a background PHP runner going? Both work; they suit different jobs. Here is a side-by-side comparison from real projects we run for clients.
At a glance
| Cron job | Background PHP runner | |
|---|---|---|
| Fastest frequency | Once per minute | Every few seconds |
| Overlapping runs | Possible if a run is slow (needs a lock file) | Never — next call waits for the previous one |
| Survives server restart | Yes, automatically | No — must be restarted |
| Shared hosting | Fully supported | Depends on host limits for long processes |
| Live monitoring | Usually just email/log output | Live log, uptime and countdown possible |
| Error recovery | Next scheduled run | Built-in retry after a short delay |
| Best for | Daily reports, token refresh, cleanup, minute-level sync | Near-real-time sync, long batch downloads |
Choose cron when…
- The job runs every minute or less often.
- Missing one run is not a disaster.
- You want the most reliable, "set and forget" option on shared hosting.
- Examples: refreshing an API login token every few hours, syncing metal rates every minute, sending a daily report, deleting temp files.
Always add a lock so slow runs do not overlap:
$lock = fopen(__DIR__ . '/sync.lock', 'c');
if (!flock($lock, LOCK_EX | LOCK_NB)) exit; // previous run still busy
// ... do the sync ...Choose a background runner when…
- Data must be fresher than one minute.
- Each run is heavy (for example "download 300 hotels" taking 60–120 seconds) and must never overlap.
- You want to watch progress live and stop it on demand.
- Examples: hotel availability sync for a travel booking site, bulk catalogue import, catching up a backlog.
The hybrid pattern we recommend
For important syncs, use both:
- A background runner does the fast, continuous work.
- A cron job every 5 minutes checks that the runner's log file was updated recently. If not, it sends an alert (email/SMS/WhatsApp) or restarts the runner.
This gives you seconds-level freshness with cron-level reliability.
Security for both
- Sync endpoints should not be public — require a secret token or allow only your server's IP.
- Cron-only scripts should refuse web requests (check
php_sapi_name() === 'cli'). - Any dashboard that starts or stops a runner should use CSRF protection on the start and stop actions and should only call public URLs.
The Cron URL Runner is our ready-made background runner with these protections.
Quick answers
Which is more reliable, cron or a background loop?
Cron is more reliable for jobs every minute or slower because the system restarts it every time. A background loop is better when you need seconds-level frequency, but it needs auto-recovery and monitoring.
Can I use both together?
Yes. A common pattern is a background loop for fast syncing plus a cron job every few minutes that checks the loop is alive and restarts it if needed.