How to schedule tasks in Replit apps (the missing scheduler)

You used Replit Agent to build something useful. A small SaaS, a webhook handler, a Telegram bot, a dashboard. It works. Today you want it to run a small task on a clock. Send a daily summary email at 9am. Recompute a leaderboard every hour. Poll a vendor every five minutes. You opened the deployments tab, found "Scheduled Deployments", and then one of three things happened: a surprise bill at the end of the month, a job that ran twice when it should have run once, or a job that ran late and nobody noticed for two days. Here is what teams who run more than one recurring task on Replit actually do, and the cost math behind it.

The cousin post for Bolt.new users lives at How to schedule tasks in Bolt.new apps. The pillar that covers every AI app builder side by side is How to add scheduled tasks to your AI-built app.

You built an app with Replit Agent. Now you want it to run something every Monday at 9am.

The exact moment a Replit user reaches for "Scheduled Deployments"

You shipped the app. The agent wrote the route. Pressing the button on the deployed URL works. You want the same route to fire on its own at 09:00 every Monday in Europe/Berlin without anyone clicking anything. You re-prompt the agent: "make this run automatically every Monday morning." The agent suggests Replit's own product, Scheduled Deployments. You click the deployments tab, pick "Scheduled", paste a cron expression, set a timezone, and deploy.

Why "schedule a task" is not the same as "deploy on a schedule"

A Scheduled Deployment is a different shape from a route running on a schedule. Every fire spins up a fresh deployment container, runs your entrypoint command, then tears the container down. That fits "run this nightly script that needs a build step". It is a heavier shape for "ping a URL my existing app already exposes". And the billing tracks the heavier shape: scheduler fee plus per-second compute on a fixed machine size, not "one HTTP call".

What Replit Scheduled Deployments actually do

Replit's Scheduled Deployments docs are clear about the moving parts. Read them before you trust this section.

1-minute minimum cadence, full cron expressions, per-job timezone

The cadence floor is one minute. You write a real five-field cron expression (no plain English here) and pick an IANA timezone per deployment. That part is genuinely good.

One machine size, 1 vCPU and 2 GiB, 11-hour max runtime

Every scheduled run lands on the same machine size. There is no "tiny machine for the 200ms ping". You pay for 1 vCPU and 2 GiB even if your job uses 50 MiB of memory and finishes in 400 milliseconds. The max runtime is 11 hours, which is generous on the upper end. The floor is the same.

$0.10 per month scheduler fee plus $0.000028 per second of compute

Per Replit's deployment pricing, each Scheduled Deployment is billed as a separate deployment with two line items: a flat $0.10/mo for the scheduler and $0.000028 per second of actual run time. That math is innocent for a 30-second job once a night. It scales unpleasantly when the cadence is "every minute".

No concurrency cap, slow jobs at minute cadence stack up

There is no native "skip if previous run is still running". If your every-minute job sometimes takes 90 seconds, the next fire starts anyway and you have two containers doing the same work, charged twice. The open Replit community thread "Cronjobs don't run consistently" is partly this and partly the regular noise of distributed scheduling, but the concurrency footgun is real.

The 60-second fix (using your existing Autoscale or Reserved VM deployment)

If your app is already deployed as Autoscale or Reserved VM, you already have a public URL. Use it. You do not need a second deployment to run a clock.

Step 1: prompt the agent to add a route

Open the agent and ask: "Add a route at /api/run-daily-task that does X. Require a header called X-Cron-Token with the value from an environment variable named CRON_TOKEN. If the header is missing or wrong, return 401."

The agent writes the route. Set the CRON_TOKEN secret in the Replit Secrets pane. Test the route once with the header set; confirm 200.

Step 2: deploy as Autoscale and copy the URL

If the app is not deployed yet, click Deploy and pick Autoscale (it scales to zero between calls, so idle cost is near zero). Copy the public URL. It looks like https://your-app-name.replit.app/api/run-daily-task.

Step 3: create a schedule in Crontap

Open Crontap and click New schedule.

URL. Paste the Replit URL from Step 2.
Method. POST or GET to match your route.
Headers. Add X-Cron-Token: your-token-value.
Cadence. Type plain English ("every Monday at 9am", "every 5 minutes") or paste a cron expression. Crontap previews the next 5 fires inline.
Timezone. Pick the IANA zone that matches the schedule's intent. Each Crontap schedule has its own; no global app timezone.

Step 4: press "Perform test" and verify

Crontap fires one real call. You should see a 200 in Crontap's run history and a matching row in your Replit deployment logs. If you see 401, the token in Crontap and the env var in Replit do not match. If the first call is slow on Autoscale, that is a cold start; the next call within the keep-warm window is fast. Add a failure alert in Crontap (email or webhook to Slack, Discord, or Telegram) so the next 4xx or 5xx pings you immediately.

Fix this in 60 seconds with Crontap. Free forever tier. Three schedules. No credit card. Schedule your first job →

Crontap vs Replit Scheduled Deployments (the honest comparison)

Both products work. The differences are about where you are paying and what you get for it.

When Scheduled Deployments is the right call

Replit Scheduled Deployments earn their keep when:

You have one nightly script and no other deployment for the app. The flat $0.10/mo scheduler fee plus a short run is genuinely cheap, and the integration with Replit's deploy and secrets surface is one click.
The job is CPU-heavy for under two minutes. A daily report generator that pulls from a database, renders a PDF, and emails it lands here. The 1 vCPU / 2 GiB box is right-sized for that shape.
You want everything in one product. Code, deploy, schedule, logs, billing, all in Replit. The single-vendor convenience is real, especially if you are the only operator and you already pay Replit for the rest of the stack.
The job needs the full Replit deployment environment: your repl's filesystem, secrets, build steps. Maintaining a separate long-lived HTTP route for it would be more work than it is worth.

That covers a non-trivial fraction of "I have one script that should run nightly" cases. The pricing is straightforward, the tooling is integrated, there is nothing to fix.

When external cron wins

An external scheduler reads cleaner when:

You have more than one schedule on the same app. Each Scheduled Deployment is a separate deployment with its own $0.10/mo scheduler fee, and they share no state. One Crontap dashboard holds all of them.
Your job is short and frequent. The "always 1 vCPU / 2 GiB" baseline is overpriced for a 400ms ping that fires 43,200 times a month.
You want predictable flat pricing instead of per-second compute billing that climbs with cadence.
You want concurrency safety (skip the next fire if the previous is still running) without writing your own lock in code.
You want to schedule non-Replit targets too (a Supabase Edge Function, a Bolt.new endpoint, a third-party webhook) from the same dashboard.

A worked cost example: a 30-second job every minute

This is a real shape. A polling job, a leaderboard recompute, a webhook fan-out.

Replit Scheduled Deployments: 30 seconds × 43,200 fires per 30-day month = 1,296,000 seconds at $0.000028 per second = about $36.29/mo in compute alone, plus the $0.10 scheduler fee.
Crontap: $3.25/mo billed annually, flat, for unlimited schedules at minute cadence. The Replit app itself still bills compute when the route runs (Autoscale only bills the warm seconds), but the schedule costs the same regardless of cadence.

The Autoscale compute for the actual route still happens in both shapes; the difference is whether you pay Replit a second time for the scheduler container. At minute cadence with a non-trivial run time, you do.

Real things teams schedule on Replit apps

Four shapes from actual customer setups, lightly anonymized.

Hourly leaderboard recompute

A competitive-app SaaS recomputes its leaderboard every hour. One Crontap schedule at hourly cadence points at /api/recompute-leaderboard. The Replit Autoscale deployment scales from zero to one container, does the work in 12 seconds, scales back to zero. Total Replit compute is a few dollars a month; the Crontap free tier covers the schedule.

Daily user notification at 17:00 local

A booking app sends an end-of-day summary at 17:00 Europe/Berlin. One Crontap schedule, daily cadence, Europe/Berlin timezone, points at /api/end-of-day-summary. The schedule definition is one line of timezone, no DST math, no Replit redeploy when business hours change.

Weekly Monday 09:00 KPI digest

A two-person team gets a Monday-morning KPI summary in Slack. The Replit route fetches the numbers and posts to a Slack incoming webhook. The Crontap schedule is 0 9 * * 1 in America/New_York. One schedule, free tier, no second deployment.

Polling a third-party API every 5 minutes

A real-time dashboard polls a vendor every five minutes. The Replit route reads the vendor, writes the result to the database. The Crontap schedule is */5 * * * * in UTC. Crontap logs response time per call, so if the vendor or Autoscale cold-starts spike, you see it without opening Replit.

FAQ

Will Crontap still work if my Replit deployment scales to zero (Autoscale)?

Yes. Autoscale wakes on the first request and serves it cold; subsequent requests inside the keep-warm window are fast. Crontap reports response time per call, so you can see whether cold-start latency matters for the job. If the cold start is consistently slow and the job is time-sensitive, switch the deployment to Reserved VM so the app stays warm continuously.

How do I keep my Replit deployment from costing more than the cron itself?

Use Autoscale, not Reserved VM, for endpoints that are only fired by Crontap. Autoscale bills warm seconds; an idle Reserved VM bills 24/7. Make the route return as fast as possible (kick off slow work asynchronously when the response does not need it). Add a short X-Cron-Token check at the top of the handler so unauthorized calls fail in microseconds and never hit your business logic.

Can I migrate an existing Scheduled Deployment to external cron?

Yes. Copy the script's logic into an HTTP route on your existing Autoscale or Reserved VM deployment. Add a token guard. Create the matching Crontap schedule with the same cron expression and timezone. Run both for a week, confirm the new path fires on time, then delete the Scheduled Deployment. The cron expression syntax is identical in both products, so the schedule definition itself ports over verbatim.

Does this work on Replit's free Starter plan?

The free plan can host the app inside the workspace, but Autoscale and Reserved VM deployments are paid features. If you are on Starter, you can build and test the route in the editor; you need a paid plan to deploy it to a stable public URL. Crontap's free tier covers three schedules at hourly cadence either way. The cheapest reliable setup is one paid Replit deployment for the app plus Crontap's free tier for the schedule.

Is Crontap a drop-in replacement for Replit's own scheduler?

For URL-triggered work, yes. Crontap fires HTTP requests on a clock; Replit Scheduled Deployments run an entrypoint command in a fresh container. If your scheduled work is "run this command", Scheduled Deployments are the natural shape. If your scheduled work is "call this URL my deployed app already exposes", Crontap is the cheaper and more flexible shape.