Bun has no built-in cron primitive, but the paved way on DenkOps is denkops.cron from the DenkOps SDK, not a hand-rolled setInterval: it schedules code straight from inside your always-on Hono slot, so there's no external scheduler to run and no imposed per-invocation timeout to work around. It persists last-run state to /persist and re-arms itself on restart, so you never have to hand-roll setInterval or track that state yourself. If you want the schedule itself visible on the platform, or triggerable outside your process, use managed declarative cron instead: a cron entry in denkops.json that DenkOps calls as an HTTP request on schedule, listed and manually runnable via the MCP list_crons and run_cron tools and the dashboard's Scheduled jobs panel.
import denkops from "@denkopsai/sdk";
import { Hono } from "hono";
const app = new Hono();
app.get("/health/last-run", (c) => c.json(denkops.cron.status("nightly") ?? {}));
// Runs at 02:00 UTC every day, inside your always-on slot. State persists to /persist and
// re-arms on restart, no setInterval to hand-roll, no per-invocation timeout.
denkops.cron("0 2 * * *", async () => {
await runNightlyJob();
}, { name: "nightly" });
export default app;Deploy it: install the plugin, say "deploy on DenkOps", and get a live SSL URL.
Start on DenkOps →Yes. denkops.cron schedules code in-process, and because the slot keeps that process running continuously, its schedule reliably fires on time with no separate cron infrastructure.
Yes. denkops.cron persists last-run state to /persist and re-arms itself on restart, so you don't lose track of the schedule across a redeploy like you would with a plain in-memory setInterval.
Not directly, denkops.cron runs in-process. For that, use managed declarative cron instead: add a cron entry to denkops.json pointing at a route, then list and run it with the MCP list_crons and run_cron tools or the dashboard's Scheduled jobs panel.