API hosting

Cron job hosting.

Scheduled-job products built on serverless functions have a habit of missing a beat: cold starts push the actual run a few seconds late, or a job that runs long gets killed before it finishes. On DenkOps the scheduler lives inside your own always-on slot, it's your process, running your schedule, on a machine that's already awake.

# a plain scheduler, in-process, node-cron, APScheduler, whatever you use
$ ls
scheduler.py requirements.txt
 
deploy on DenkOps
→ running · slot: always-on · next run logged at 02:00 UTC
/persist mounted · egress: blocked by default

Log the last-run timestamp and job output to /persist so a restart doesn't lose the history of what actually ran. Add only the destinations the job calls out to, an email API, a Slack webhook, a database, to the egress allowlist.

Start on DenkOps →

FAQ

Can I just run a cron scheduler on DenkOps instead of a managed cron product?

Yes. Because a slot is a real always-on process, you can run node-cron, APScheduler, Python's schedule, or a plain while-loop with a sleep, exactly like you would on a server you own. There's no separate scheduling product to configure, the scheduler is just part of your app.

What happens if my scheduled job overlaps or runs long?

That's between your code and the slot's CPU/RAM, not a platform limit, there's no per-invocation timeout to hit. Write a last-run timestamp or a lock file to the durable /persist disk if you need to guard against overlapping runs after a restart.

← API hosting · Express cron job guide · FastAPI cron job guide