Running Scheduled Jobs, as easy as 1,2,3

When I added scheduled jobs in QueueRun, I started with two simple goals:

1. Get me from "I need to run this job" to "in production" in under 2 minutes
2. Beyond that first-minute experience, make it easy to manage and monitor

2 Minutes to Production

Step 1: write the function you want to run on a schedule:

// This is schedules/daily_report.ts
export default async function() {
  // Do some work to generate and email report
  // ...
};

Step 2: export the schedule constant that tells the job when and how often to run:

// In the same file we add
export const schedule = "daily";

Step 3: deploy:

$ npx queue-run deploy

And if you want to make sure the job was deployed successfully, and when it's expected to run next:

$ npx queue-run status

Behind the scenes QueueRun packages your back-end into an AWS Lambda function and deploys it to your AWS account.

It uses AWS EventBridge to schedule triggers, so your function would run like clockwork.

QueueRun will automatically add, update, and delete triggers to match the scheduled functions in your codebase. You don't have to write CloudFormation, log into AWS consoles — it's as close as we get to zero-ops.

You can schedule jobs to run at minute intervals, every day, every Tuesday at 5 pm (don't forget, all times are UTC), on the second Monday of the month, whatever cron supports.

Make It Easy To Manage

Life happens. You discover bugs in the code, a service you use breaks, a job expands to take a longer time than originally planned for.

Making deployment easy is just one part. The other part is having visibility into and control over your scheduled jobs.

There's a dev server you can use to test your code locally.

There will come a time when you need to run a scheduled job on demand, in production, and there's a command for that.

If you want to temporarily take a scheduled job out of rotation, no need to delete the code, change the schedule to "never".

You can combine the two: deploy a job that's scheduled to run "never", and use the schedule command to run it on demand. I call this feature "on my schedule".

For large workloads, and when you need resiliency, you can use scheduled jobs in combination with FIFO and standard queues, all part of the same codebase.

The metrics command will show you performance metrics, and the logs command will tail the server logs for you.

Should be easy to integrate with a 3rd party logging service (I'm partial to Logtail), an error reporting service (Sentry still my favorite).

You also want a separate service to monitor your back-end: cronitor.io and healthchecks.io are both excellent choices.

Give it a try and share your experience. Do you think we can make this even better?