Schedulers: Cron Jobs Without a Cron Server

Intro

0:00 Code that runs on a clock : every minute, every night, on weekdays at nine. No cron server, no double runs, and every run on record. In this video, a low stock alert for the buyers of Calm Home.

Jobs, the usual way

0:14 Background jobs usually mean a crontab on one server, which nobody remembers, the same job on two servers, so two emails go out, no record of what ran and what failed, and a job that dies with its server. With API Maker, a scheduler is a function with intervals, it runs once on the cluster, every run is listed with its time and result, and another server takes over when one goes away.

0:40 In this video : a scheduler and its intervals, cron expressions, the run panel, run now, pause and stop, timeouts, and one run per cluster.

A scheduler and its intervals

0:50 APIs and Logic, Schedulers. Add New : on the left what it is, on the right when it runs. The name, low_stock_alert, a timeout of two minutes, and Active. An interval : every minute, read on the clock of Kolkata. Each interval has its own time zone. The run panel counts down to the next run already, and lists the next five : what the server fires is what you see.

Cron expressions

1:19 A second interval, as a cron expression. Zero, zero, nine, any day, any month, Monday to Friday : the panel checks it as it is typed, by the rules of the server. Its next runs : Monday nine o'clock, Tuesday, and on. Six fields : the second first, then the minute, the hour, the day of the month, the month and the day of the week. Names work too, jan to dec, sun to sat, and presets such as @daily or @weekdays.

1:50 Five fields, as crontab.guru writes them, run at second zero.

The run panel

1:55 The Code tab. The job reads the inventory of SQL Server, keeps the rows at or under their reorder level, names them from the products of MongoDB, and writes one alert into stock_alerts. The same g as a custom API, in any of the eight languages. Save. A server holds it at once : Running, on the server video1, with its schedule and its timeout. Open it again : Runs on video1, and the countdown to the next minute.

2:26 The minute comes : the run is listed, with its time, its interval and how long it took.

Run now

2:32 No need to wait for the clock. The vial of the row opens the scheduler in API Testing, with its timeout as a header. Send runs it once : fifteen products to order again, in milliseconds. The Logs tab has the line g.logger wrote. And what it wrote : in MongoDB, catalog, stock_alerts, a query, the newest row. One alert, fifteen products, each with its name from MongoDB and its quantity from SQL Server.

Run time

3:08 After a few runs, the Scheduler List tells how the job does, from the numbers of Analytics: its average run time, and its runs over the day, with any failure in red. One click opens the details of its runs: its p95 and the other percentiles, the slowest run, and the runs hour by hour. A job that slows down shows it here, before anybody waits for its data.

Pause and stop

3:32 Pause or stop it without deleting anything. In the dialog, the interval every minute is switched off : the next run is Monday at nine. Untick Active, and nothing starts a run. Update : every server stops it at once. No server, a grey dot.

Timeouts

3:50 A job that waits on a slow service, with a timeout of one minute. Its run panel : running now, its seconds counting up. At one minute it is stopped : the run is listed in red, with its error, API did not respond in sixty thousand milliseconds. The next minute starts its own run : a slow run never holds up the next one.

Once per cluster

4:13 On a cluster, each scheduler runs on one server. Every server says it is up in Redis, every five seconds. From the same list, each server works out the owner of every scheduler, by rendezvous hashing : they agree without talking, and the schedulers spread evenly. The owner holds a key in Redis for twenty seconds, renewed while it runs : a scheduler never runs on two servers at once.

4:38 A server goes away. A clean stop gives its keys back : the others take its schedulers within five seconds. A crash leaves its keys to expire : within twenty seconds. And only its share moves : the schedulers of the other servers stay where they are.

Good to know

4:55 The next run may be on another server : keep what a run needs in the cache, not in memory. Schedulers are files in Git, and travel with a pull. A log profile records every run, and its answer with Log Response. Schedulers of a developer account never run : developers work without firing real jobs.

Built on standards

5:16 Every job has a name, intervals with time zones, a timeout and a record of its runs. What the panel shows is what fires : the same cron engine reads both. And an AI assistant writes a job like a custom API : one function, the same g.

Recap

5:32 To sum up. A function, intervals and a time zone each. Cron expressions, checked as they are typed. The next runs and the past ones, side by side. Run now, pause, stop, and a timeout. Once per cluster, with failover. Next : authorization, who may call what. API Maker. Build faster, spend smarter, deliver better.