How to Run Cron Jobs Without a Server

Every cron tutorial starts the same way: SSH into your server, open crontab, add a line. That works when you have a VPS or dedicated box. But a growing number of developers don't have one. Their app runs on Vercel or Netlify. Their WordPress site lives on managed hosting with no terminal access. They just need something to happen every 15 minutes, and the only tool everyone recommends requires a Linux machine they don't have.

You don't need one. Haven't for years. Here are five ways to run scheduled tasks without owning a server, what each costs, and where each breaks down.

Cloud cron services (the simplest option)

A cloud cron service is basically a hosted crontab. You give it a URL, pick a schedule (say, every 5 minutes), and the service sends a request to that URL on time. No server to manage, nothing to install.

Your app just needs a web address that does something when visited. A page that clears old records. A script that sends a daily email. A WordPress endpoint that processes scheduled posts. The cron service doesn't care what's behind the URL. It just opens it on schedule.

Here's how the main ones compare:

cron-job.org gives you unlimited free jobs. Hard to beat on volume. But there's no uptime guarantee, the 30-second timeout is tight for anything slow, and if your task quietly fails while the page still loads fine, you'll never know. EasyCron's free tier is so limited (one job, 20-minute minimum) that it's basically a trial. FastCron sits in the middle with a generous free plan and a WordPress plugin that sets everything up for you.

One gap most of these share: they visit the URL, but they don't check what actually happened. If your page loads with a "200 OK" status but the code inside threw an error, most services will still report success. More on that later.

GitHub Actions (free for public repos)

If your code is on GitHub, you already have a free way to run tasks on a schedule. You add a small config file to your repo, and GitHub runs your script automatically. Here's what it looks like:

# .github/workflows/scheduled-task.yml
name: Run cleanup
on:
  schedule:
    - cron: '*/15 * * * *'  # every 15 minutes
jobs:
  cleanup:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: node scripts/cleanup.js

Public repos get unlimited free minutes. Private repos get 2,000 minutes per month on the free plan (roughly 66 hours). For a script that runs every 15 minutes and takes 10 seconds, that's about 3 hours of compute per month. Plenty.

Where it falls short:

Timing. GitHub doesn't promise your task runs exactly when scheduled. During busy hours, delays of 5 to 30 minutes happen regularly. Their own docs warn about this. If you need something to fire within a minute of the scheduled time, this won't cut it.

Startup time. Every run boots a fresh virtual machine, installs your project's dependencies, downloads your code. A 10-second script might take 45 seconds total. For just opening a URL every few minutes, that's a lot of overhead.

No alerts when things break. If your script fails, there's a note in the Actions tab on GitHub. Maybe an email if you've turned that on. No Slack message, no text, no webhook. You'd have to build that yourself.

Good for: cleaning up databases, generating reports, running scrapers. Bad for: anything time-sensitive or anything that just needs to open a URL.

Built-in cron on platforms like Vercel, Railway, and Render

Most modern hosting platforms now let you schedule tasks right in their dashboard.

Vercel lets you attach a schedule to any of your app's pages. You add a few lines to a config file:

{
  "crons": [{
    "path": "/api/cleanup",
    "schedule": "0 */6 * * *"
  }]
}

On the free plan, you get 2 scheduled tasks, but they can only run once per day. The paid plan ($20/month) removes that limit. And you can only schedule pages within your own Vercel project, not external URLs.

Railway works similarly. You set a schedule for a service, and Railway starts it at the right time. Render offers scheduled tasks as a separate service type. Both have free tiers with some limitations.

All three follow the same pattern: your code runs on their servers, on their schedule. Works great when your app already lives there. Doesn't help when you need to trigger something on a different server, like a WordPress site or an external API.

Cloud functions (AWS Lambda, Google Cloud)

AWS and Google Cloud both let you write a small piece of code that runs on a schedule without any server. On AWS, you'd write a Lambda function and connect it to a scheduler called EventBridge. On Google Cloud, you'd use Cloud Scheduler with a Cloud Function.

These are the most reliable options on this list. Cloud providers guarantee uptime. Scheduling is accurate to within seconds. And the free tiers are generous: AWS Lambda gives you 1 million free runs per month, which is way more than most cron jobs need.

The downside is setup. You need an AWS or Google Cloud account, you need to configure permissions, write a function, and wire everything together. For someone who just wants to open a URL every 5 minutes, that's like renting a warehouse to store a shoebox. Google Cloud Scheduler is simpler, but you still need a project with billing turned on.

Worth knowing: if your AWS function crashes, the scheduler retries it twice and then gives up. The error shows up in a log that you'll only see if you go looking for it. No one gets notified by default.

CI/CD pipelines (the workaround that works)

GitLab, Bitbucket, and CircleCI all let you run tasks on a schedule through their build systems. You set it up the same way you'd configure automated tests, but instead of running on every code push, it runs on a timer.

This makes sense when the task is tied to your codebase: rebuilding a sitemap, clearing a cache, sending a weekly report that pulls data from your app. Everything stays in your repository, version-controlled.

The limit: most of these only go down to once per hour. If you need something every 5 minutes, or if you just need to open a URL, this approach is too heavy.

Quick comparison

If you just need a URL opened on a schedule, a cloud cron service gets you there in two minutes. No infrastructure, no code to deploy.

If you want to run your own script and it lives in a GitHub repo, GitHub Actions is the natural pick. Just accept that timing won't be exact.

If your app already runs on Vercel or Railway, use the platform's built-in scheduler. No reason to add another tool for something it handles natively.

For anything that needs to fire exactly on time with no exceptions, AWS or Google Cloud are the most reliable. But for 90% of "open this URL every 5 minutes" situations, they're overkill.

The part everyone skips: knowing when it breaks

Every option on this list has the same blind spot. They run the task. They don't tell you whether it actually worked.

GitHub Actions shows a green checkmark if your script finished without crashing, even if it processed zero records. Vercel logs "completed" even if the page threw an error that got caught silently. cron-job.org reports "200 OK" even if the database call inside your script timed out and nothing happened.

Running the task is half the job. Knowing the result is the other half.

WatchCron's Cloud Cron covers both. It opens your URL on schedule and records what came back: the status code, how long it took, and the response content. If the status changes from OK to an error, if the response time spikes, or if the request times out entirely, you get a notification through Slack, Telegram, email, or Discord. The free plan includes 3 scheduled tasks, enough for the typical "open one URL every 5 minutes" setup.

For tasks that run somewhere else (GitHub Actions, AWS, your own server), heartbeat monitoring works the other direction: your task pings WatchCron when it finishes, and if the ping doesn't arrive on time, you get an alert.

Common setups that don't need a server

WordPress on managed hosting is the one we see most. Your host (Kinsta, WP Engine, Flywheel) runs the server, but WordPress needs its internal scheduler triggered every few minutes to publish scheduled posts and run plugin tasks. A cloud cron service opens wp-cron.php on a timer. Two minutes to set up. We wrote a full walkthrough in the WP-Cron replacement guide.

Nightly API calls are another common one. Your app needs to call a billing endpoint or sync data with a third-party service at 2 AM every night. Point a cloud cron at the URL, set the schedule to 0 2 * * *, done.

Free-tier hosting has a trick worth knowing about. Render, Railway, and Fly.io put free apps to sleep after 15 minutes without traffic. A cloud cron pinging your app every 10 minutes keeps it awake. Not pretty, but it works. And if you run a static site that pulls content from a CMS, a scheduled GitHub Action can trigger a rebuild every day without any server involved.

Where to start

Pick the method that fits your situation. Not sure? Start with a cloud cron service. Paste your URL, pick a schedule, save. Working cron job in under two minutes. You can always switch to something more complex later if you need to.

For help with scheduling syntax, the cron expression builder lets you put together and test expressions visually. The complete cron jobs guide explains the five-field format from scratch. And if you want to compare cloud cron services side by side, the online cron services comparison covers pricing, features, and limits for every major provider.