A scheduled job is a task that runs automatically at a fixed time or on a repeating interval, with no human pressing start. Run a backup every night at 2 AM. Send an invoice summary every Monday at 8. The schedule fires, the work happens, and your team wakes up to the result.
Think of a coffee machine with a timer. You fill it the night before and set 6:30 AM. You are still asleep when it brews, but the coffee is ready when you walk in. A scheduled job is that timer for your software: the work runs on the clock, not on someone remembering to do it. On Unix systems this is most often a cron job, defined by a small line that says exactly when to run.
The trigger here is time itself, which is what separates it from event-based automation. A scheduled trigger is the part that watches the clock, and scheduled jobs pair naturally with batch processing, where a pile of work gets handled in one off-hours run instead of one item at a time.
A couple of things trip people up. Time zones matter: a job set for “2 AM” should be clear about which zone, or daylight saving can shift it by an hour. And two runs should not overlap, so if last night’s job is still going when tonight’s starts, you want it to wait rather than pile up. Those small details are the difference between a job you trust and one you babysit.
At TopDevs we use scheduled jobs for the quiet background work, reports, syncs and cleanups, and we always wire in a failure alert so a skipped run never slips by unnoticed.
