You opened Bolt.new, described the app you wanted, watched it scaffold a frontend and a backend, clicked Publish, and there it is on your-app.bolt.host. The login works. The database works. Now you want it to send a daily summary email at 9am, or sync a third-party API every hour, or post yesterday's signups to Slack on Monday morning. You re-prompt the agent. It writes you a function. The function runs when you press the button in the preview. It never runs on its own.
Bolt builds the function. You still need a clock to call it. Here is the 5-minute pattern Bolt builders are using, with no extra credits, no Supabase SQL detour, and no all-nighter wrestling with the agent to "make it run on a schedule". The cross-platform pillar comparing the same pattern across Lovable, Replit, v0, base44, Tempo, and Create.xyz is the place to start if you have not yet picked an AI app builder.
Why Bolt.new does not ship a scheduler
Bolt is great at scaffolding. It is also honest about its scope: ship the app, host the app, expose the public URL. The clock is not part of the package.
Bolt scaffolds full-stack apps inside StackBlitz
Bolt runs your app live in a StackBlitz WebContainer while you build. The Express routes you see in the preview run in the WebContainer, not on a server. Anything you wired up as "set an interval and call this every minute" dies the moment the preview tab closes. That is fine while you build. It is not fine once you ship.
Bolt Cloud and Netlify host your deployed app, but neither surfaces a cron primitive
Once you click Publish, Bolt deploys to Bolt Cloud or to your connected Netlify account. Bolt Cloud's Server functions docs list every supported use case for the deployed backend: HTTP endpoints, webhook receivers, OG image generation, transactional emails. Search the page for "schedule" or "cron" and you get nothing. The same is true on Netlify Scheduled Functions, which are a separate beta feature with their own 30-second cap. Neither product gives the Bolt user a "run this every X" toggle anywhere.
Supabase pg_cron and Bolt Database, only one is a real scheduler
If you wired your app to Supabase via the official Bolt Supabase integration, pg_cron is sitting there in the SQL editor. It is a real scheduler. It is also SQL, and the whole point of using Bolt was to avoid writing SQL by hand. Bolt Database (the built-in option) gives you server functions but no pg_cron. Either way, the path the agent does not take you down is "open Supabase, write SQL, schedule a function from the database". You wanted a click path, not a SQL session.
So the pattern Bolt users settle on is the boring, durable one: keep the function Bolt already built, put the clock somewhere else.
The 60-second fix
The setup has four steps. Read them once, then run them in order. You should be done before the kettle finishes boiling.
Step 1: prompt Bolt for a public function with a shared-secret check
Open your Bolt project. Send a prompt like:
Add a server function called
nightly-digestthat emails me yesterday's new signups using Resend. It should be callable from a public URL and require a headerX-CRON-TOKENmatching an env varCRON_TOKEN. Return 401 if the token is missing or wrong.
Bolt scaffolds the route, adds the env var, wires the email send. Set the value of CRON_TOKEN in your project's environment variables to a strong random string. From a terminal:
openssl rand -base64 32Copy that into your Bolt env vars (Project Settings, Environment Variables). Save.
Step 2: copy the public URL
Click Publish. Once the deploy finishes, the function is reachable at the public URL Bolt prints in the deploy panel. The shape is one of two, depending on where you deployed:
- Bolt Cloud:
https://your-app.bolt.host/api/nightly-digest. - Netlify:
https://your-app.netlify.app/.netlify/functions/nightly-digest.
Either is a normal HTTPS URL. Test it in your browser or with curl first. With the wrong token you should see 401. With the right one in X-CRON-TOKEN, you should see the digest fire.
Step 3: paste the URL into Crontap
Open Crontap, sign in (free tier, three schedules, no credit card), and click New schedule.
- URL. Paste your function URL.
- Method.
POST. - Headers. Add
X-CRON-TOKEN: <the strong random string from Step 1>. - Cadence. Type plain English ("every day at 9am", "every hour", "every Monday at 09:00") or paste a cron expression. Crontap previews the next 5 fires inline.
- Timezone. Pick the IANA zone the schedule should run in.
Europe/Berlin,America/Los_Angeles,Asia/Singapore, you get the idea. Bolt does not have a per-app timezone story; Crontap is per-schedule, no DST math on your side.
Step 4: press "Perform test" and confirm
Click Perform test. Crontap fires a single real call. You should see:
- A 200 in Crontap's run history.
- The expected side effect (the email arrives, the row is written, the Slack message posts).
- The function showing up in Bolt's deploy logs.
If you see 401, the header value does not match the env var. If you see 5xx, the function body itself failed and the response includes the error. Add a failure alert in Crontap (email, Slack via webhook, Discord, Telegram) so the next time anything breaks, you find out in seconds, not the next morning.
Fix this in 60 seconds with Crontap. Free forever tier. Three schedules. No credit card. Schedule your first job →
What people try first (and why each gets frustrating)
Most Bolt builders try one of three things before settling on external cron. None of them are wrong, exactly. They are just heavier than the job calls for.
Always-on Express server with setInterval
The first instinct, especially if Bolt scaffolded an Express backend, is to put a setInterval at the top of server.ts. Works in the preview tab. Works on a Render or Railway deploy if the dyno never sleeps. On Bolt Cloud's serverless model and on Netlify, there is no always-on process, so the interval never gets a chance to tick.
Supabase pg_cron in SQL
If you connected Supabase, pg_cron is real. It is also SQL, and the function you want to call lives in your Bolt server, not inside Postgres. To make it work end to end, you write a pg_net HTTP request from inside the database to call your Bolt URL. That is two technologies and one DB extension to learn for one cron line.
Schedule by Zapier
Schedule by Zapier as a trigger plus a webhook step pointing at your Bolt URL works on day one. It also charges one Zapier task per scheduled run. A minute-cadence Zap is 43,200 tasks a month, which exits the free and Starter tiers fast. The Zapier task cost post walks the math.
External cron sidesteps all three. The function Bolt already built keeps its public URL. The clock lives outside Bolt's runtime, outside Bolt's tokens, and outside Zapier's task counter.
Real things teams schedule on Bolt.new apps
A short list of cadences that come up often, paired with the Bolt function shape that handles them.
- Daily blog post auto-generation at 03:00 UTC. The pattern from the r/boltnewbuilders landing-page thread where a Bolt app drafts a post overnight. One Crontap schedule, daily. Bolt function pulls the topic queue, calls the LLM, writes the row.
- Hourly waitlist sync to Resend. Function reads new signups from the last hour, sends a "you're in" email. One Crontap schedule, hourly, no per-row recursion.
- Weekly Monday 09:00 user-stats email. Aggregates last week's events, sends an HTML digest. One Crontap schedule,
0 9 * * 1in your IANA zone. No DST drift. - Recurring Stripe subscription reconciliation. Nightly pull of active subscriptions, write back to your DB. One Crontap schedule, with a longer 5xx retry window because Stripe paginates.
The same pattern lives on cousin platforms; the Lovable scheduler post and the Replit Scheduled Deployments comparison walk through the equivalent shape in their own dashboards. The cron jobs for Bolt spoke is the canonical Bolt-only reference.
FAQ
Why does my Bolt cron run in preview but not after deploy?
The preview runs in a StackBlitz WebContainer that lives inside your browser tab, so setInterval and node-cron keep ticking while the tab is open. After deploy, Bolt Cloud and Netlify run your code in serverless functions that wake up to handle a request and shut down right after. There is no process for setInterval to tick on. The fix is to invert the relationship: an outside service (Crontap) wakes the function on a clock, the function does its work, the function exits.
Can I do this if I picked Bolt Database instead of Supabase?
Yes. Bolt Database server functions expose the same public-URL shape as a Supabase Edge Function. The function URL Bolt prints when you publish is what Crontap calls. Your X-CRON-TOKEN check lives inside the function regardless of which database backs it.
Does this consume Bolt tokens?
No. Bolt tokens are spent when you prompt the agent to write or change code, not when your deployed function runs. The schedule itself lives in Crontap. Each time Crontap calls your function, your serverless function bills its own runtime (Bolt Cloud or Netlify), not your Bolt token allowance. The "fix the cron" loops that eat tokens stop happening, because the cron is not in Bolt anymore.
Can I do this on the Bolt free plan?
Yes, with one caveat. The free Bolt plan's published apps stay reachable at the public URL, which is all Crontap needs. If your function call exceeds your free serverless quota or goes idle long enough to cold-start, the call is slower but it still runs. Pair Crontap's free tier (three schedules, hourly cadence) with Bolt's free tier and you can ship a real scheduled job for $0.
What if my function takes longer than the platform's request timeout?
Bolt Cloud and Netlify both cap individual function invocations. If your job runs longer, do not do the work in one call. Start a background job (a queue write, a Supabase row, a pg_net call) and return 200 immediately. Crontap is the trigger; the long work runs out of band.
Fix this in 60 seconds with Crontap. Free forever tier. Three schedules. No credit card. Schedule your first job →
References
- Bolt Cloud overview
- Bolt Database server functions
- Bolt Supabase integration
- r/boltnewbuilders: Everything I learned building my landing page
Related on Crontap
- Cron jobs for Bolt. The Bolt-only reference for scheduling published functions, with the auth and timezone patterns.
- How to add scheduled tasks to your AI-built app. The pillar covering Lovable, Bolt, Replit, v0, base44, Tempo, and Create.xyz in one place.
- How to schedule tasks in Lovable apps. The cousin walkthrough for Lovable Cloud edge functions.
- How to schedule tasks in Replit apps. The cousin walkthrough, including when Replit's native Scheduled Deployments are enough and when they are not.