# Free Vercel Cron Alternative: Jobs Every Minute

> Vercel's free plan runs scheduled jobs once a day, give or take an hour. On your own server, a job can run every minute for $0 extra.

Source: https://boringpush.com/blog/free-vercel-cron-alternative-every-minute

## "Hobby accounts are limited to daily cron jobs"

You schedule a job that checks for missed payment webhooks every 15 minutes. You push. The deploy fails with that message.

It's in Vercel's docs, checked on 2026-10-20. On Hobby, scheduled jobs can run at most once a day, and anything more frequent fails the deploy. Timing is loose too: a job set for 1 am "will trigger anywhere between 1:00 am and 1:59 am."

Pro lifts both limits, at $20 a month per seat plus the usage each run costs. For one small job, there's a cheaper way.

## Jobs that run when you say

On your own server, a scheduled job is just a small script you drop into a folder. Pick the folder for how often it should run: every minute, hourly, daily, weekly or monthly.

That's the whole idea. No schedule syntax to learn, no extra service to sign up for, and no per-run charge.

## Vercel's cron next to your own server

Vercel numbers come from its [cron usage and pricing page](https://vercel.com/docs/cron-jobs/usage-and-pricing) and [pricing page](https://vercel.com/pricing), checked 2026-10-20.

| | Vercel Hobby | Vercel Pro | BoringPush |
|---|---|---|---|
| Price | $0 | $20/mo per seat, $20 usage credit | $0 on the server you already run |
| Fastest schedule | Once a day | Once a minute | Once a minute |
| Timing | Within the hour (±59 min) | Per minute | Per minute |
| Jobs per project | 100 | 100 | Add as many as you like |
| What a run costs | Counts as a function call | Counts as a function call | Nothing extra |
| Two runs at once | Yours to prevent | Yours to prevent | Prevented for you |

## Add a job in three steps

**Step 1 — Write your job.** It's a short script. Say you want a health check every minute:

```js
// Example job, not shipped with BoringPush.
const res = await fetch("http://localhost:3000/api/health");
if (!res.ok) {
  console.error(`health check returned ${res.status}`);
  process.exit(1);
}
console.log("health ok");
```

**Step 2 — Try it by hand.**

```bash
npm run worker:minute
```

You see each line as it runs, exactly as the server will.

**Step 3 — Ship it.**

```bash
bp deploy
```

The next minute after the deploy, your job runs. The [background jobs section on the homepage](/#jobs) shows the same flow in a few seconds.

## What already runs for you

Your server comes with a few jobs on a schedule. Your database gets a snapshot every day and its old files are tidied up each month. Your log files are rotated each week, and old analytics rows are cleared out once they're 90 days old.

You don't set any of it up. You can leave it alone, or add your own next to it.

## Three jobs worth adding first

Three good first jobs:

- **Missed payments.** Check for payments that never confirmed, so no customer waits on a lost notice.
- **Queued emails.** Send them in small batches, so a slow mail provider never blocks a signup.
- **Health ping.** Hit your own health page, so you hear about trouble before a customer does.

Each can be a short script, and each can run every minute at no extra cost.

## Keep minute jobs small

A job that runs every minute should finish well inside that minute. Good fits are checking a payment provider for a missed webhook, sending a small batch of queued emails, or pinging your own health page.

Slow work belongs in the hourly or daily folder. If one run is still going when the next minute arrives, the new run skips instead of piling up, so your server never gets buried.

## Know this first

This is scheduled jobs, not a full job queue.

There are no automatic retries, no dashboard per job, and no way to spread work over many machines. If you need multi-step jobs with retries and a UI, a queue service is a better fit. The [Inngest comparison](/blog/inngest-alternative-nextjs-cron-workers) draws that line.

Jobs also need a server that stays on, which is the point of this post. If you deploy with Docker instead of the default route, add the schedule to your server yourself.

## Why BoringPush is the way to do this

Scheduled jobs are usually a separate service, a separate bill and a separate dashboard. In BoringPush they're a script in a folder, running on the server you already have.

That's the whole product idea: the thing you need next is already there. Every minute, for nothing extra, with your own data one line away.

## FAQ

### Is Vercel Hobby cron really once a day?

Yes, per Vercel's own docs: Hobby jobs can run once per day, more frequent schedules fail the deploy, and a job can fire anywhere within its scheduled hour. Pro and Enterprise allow once a minute with per-minute timing. All plans allow 100 cron jobs per project.

### Can my jobs use my app's data?

Yes. Your jobs run inside your app's own folder, so they can read and write the same database your app does. That's how the daily snapshot works.

### Where do I see if a job failed?

Each run adds a line to the server's job log: a tick with how long it took, or a cross with what went wrong. If any job in a run fails, that run reports failure.

### Can two runs of the same job overlap?

No. If the previous run is still going, the new one steps aside. That keeps a slow job from stacking up.

### Does it cost anything per run?

No. It's your server doing the work, and you already pay for it. There's no per-call meter.

## Keep reading

- [Free Inngest Alternative: Cron and Node Workers on a VPS](/blog/inngest-alternative-nextjs-cron-workers) — scheduled jobs vs a real job queue
- [Cron Beat Redis: $0 Background Workers](/blog/background-workers-no-redis-nextjs) — why no Redis is needed
- [Free Vercel Alternative: Host Next.js on a $6 VPS](/blog/free-vercel-alternative-nextjs-vps) — the server these jobs run on

[Get BoringPush →](/#get)