DEV Community: delay.run

How to verify HMAC-SHA256 signed webhooks in Node and Python

delay.run — Sat, 31 Oct 2026 22:40:59 +0000

If your app exposes an endpoint that another service calls (a webhook, a scheduled job URL, a callback), anyone who discovers the URL can call it too. Signed requests fix that. The sender computes an HMAC of the request with a shared secret, sends it in a header, and you recompute it and compare. Here's how to do it correctly, including the parts most implementations get wrong.

How HMAC signing works

You and the sender share a secret, for example a long random string.
For each request, the sender computes HMAC-SHA256(secret, message), where the message is usually a timestamp plus the raw request body.
The sender puts the signature (and the timestamp) in headers.
You compute the same HMAC over the same message and compare.

If someone changes the body, or doesn't know the secret, the signatures won't match.

The exact header names and message format vary by sender, so check their docs. The examples below assume headers called X-Signature (hex) and X-Timestamp (Unix seconds), signing timestamp + "." + body.

Rule 1: use the raw body

The signature covers the exact bytes that were sent. If your framework parses JSON and you re-serialize it, key order and whitespace can change, and the signature won't match. Capture the raw body.

Rule 2: compare in constant time

A normal == stops at the first different character, which leaks timing information. Use a constant-time compare.

Rule 3: check the timestamp

Without a timestamp check, an attacker who captures one valid request can replay it forever. Reject requests older than a few minutes.

Node.js (Express)

import express from "express";
import crypto from "node:crypto";

const app = express();
const SECRET = process.env.WEBHOOK_SECRET;
const TOLERANCE_SECONDS = 300;

app.post("/jobs/run", express.raw({ type: "*/*" }), (req, res) => {
  const signature = req.get("X-Signature") || "";
  const timestamp = req.get("X-Timestamp") || "";

  const age = Math.abs(Date.now() / 1000 - Number(timestamp));
  if (!timestamp || Number.isNaN(age) || age > TOLERANCE_SECONDS) {
    return res.status(401).send("stale or missing timestamp");
  }

  const expected = crypto
    .createHmac("sha256", SECRET)
    .update(`${timestamp}.`)
    .update(req.body) // raw Buffer
    .digest("hex");

  const a = Buffer.from(signature, "hex");
  const b = Buffer.from(expected, "hex");
  if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) {
    return res.status(401).send("bad signature");
  }

  const payload = JSON.parse(req.body.toString("utf8"));
  // ... do the work
  res.status(200).json({ ok: true });
});

app.listen(3000);

express.raw() keeps the body as a Buffer. timingSafeEqual throws if lengths differ, hence the length check first.

Python (Flask)

import hmac, hashlib, os, time, json
from flask import Flask, request, abort

app = Flask(__name__)
SECRET = os.environ["WEBHOOK_SECRET"].encode()
TOLERANCE = 300

@app.post("/jobs/run")
def run_job():
    signature = request.headers.get("X-Signature", "")
    timestamp = request.headers.get("X-Timestamp", "")
    try:
        if abs(time.time() - int(timestamp)) > TOLERANCE:
            abort(401)
    except ValueError:
        abort(401)

    body = request.get_data()  # raw bytes
    expected = hmac.new(SECRET, timestamp.encode() + b"." + body, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(signature, expected):
        abort(401)

    payload = json.loads(body)
    # ... do the work
    return {"ok": True}

Call request.get_data() before anything touches request.json, so you get the original bytes.

Test it locally

Generate a signed request by hand:

SECRET='test-secret'
TS=$(date +%s)
BODY='{"task":"cleanup"}'
SIG=$(printf '%s.%s' "$TS" "$BODY" | openssl dgst -sha256 -hmac "$SECRET" -hex | awk '{print $2}')
curl -s -X POST localhost:3000/jobs/run \
  -H "X-Timestamp: $TS" -H "X-Signature: $SIG" \
  -H 'content-type: application/json' -d "$BODY"

Then change one character in the body, or use an old timestamp, and confirm you get a 401.

Rotating secrets

Support two secrets during a rotation: accept a signature that matches either one, switch the sender to the new secret, then remove the old one. Keep secrets in environment variables or a secret manager, never in the repo.

Combine with idempotency

A valid signature proves who sent the request, not that it's the first time you've seen it. Retries are legitimate duplicates with valid signatures, so handlers should still be idempotent.

Signed scheduled calls

delay.run signs the HTTP requests it sends with HMAC-SHA256 and a timestamp, so the endpoint it calls on a schedule can be verified with code like the above.

Make scheduled job handlers idempotent: safe to run twice

delay.run — Sat, 31 Oct 2026 22:40:35 +0000

Any system that calls your endpoint on a schedule, or retries it after a failure, will sooner or later call it twice for the same piece of work. A network timeout after your handler finished, a retry after a slow response, two servers firing the same cron: each of these runs the job again. If your handler sends an email or charges a card, "again" is a real problem. The fix is to make the handler idempotent: running it twice has the same effect as running it once.

Why duplicates are unavoidable

Consider a scheduler calling POST /jobs/send-invoices. Your handler takes 35 seconds. The caller's timeout is 30 seconds, so it records a failure and retries. Your first run finishes anyway. Now the invoices go out twice.

You can't fix this purely on the caller's side. Without the caller knowing exactly what your handler completed, "at least once" delivery is the only safe guarantee, and handling duplicates is the handler's job.

Technique 1: an idempotency key

Give each unit of work a unique key and record it when you process it. If the key has been seen, skip the work.

# Flask + PostgreSQL example
from flask import Flask, request
import psycopg

app = Flask(__name__)

@app.post("/jobs/send-reminder")
def send_reminder():
    payload = request.get_json()
    key = payload["job_key"]  # e.g. "reminder:user42:2026-11-01"
    with psycopg.connect(DSN) as conn:
        cur = conn.execute(
            "INSERT INTO processed_jobs (key) VALUES (%s) ON CONFLICT DO NOTHING",
            (key,),
        )
        if cur.rowcount == 0:
            return {"status": "duplicate, skipped"}, 200
        send_email(payload["user_id"])
    return {"status": "sent"}, 200

CREATE TABLE processed_jobs (
  key text PRIMARY KEY,
  processed_at timestamptz DEFAULT now()
);

The unique constraint does the hard work: if two copies arrive at the same moment, only one insert succeeds.

Return a 2xx for duplicates. If you return an error, the caller retries again.

Choosing the key

The key should describe the work, not the delivery attempt:

Good: invoice-run:2026-11, reminder:user42:trial-day-3
Bad: a random UUID generated per request, a timestamp of when the call arrived

For recurring jobs, include the period: daily-report:2026-11-01. Then a second call on the same day is skipped, and tomorrow's call runs normally.

Technique 2: make the work itself naturally idempotent

Some operations are safe to repeat by design:

-- Not idempotent
UPDATE accounts SET credits = credits + 100 WHERE id = 42;

-- Idempotent
UPDATE accounts SET plan = 'pro', renewed_until = '2026-12-01' WHERE id = 42;

Setting a value is safe; incrementing it isn't. Upserts, "mark as done" flags and "recalculate from source" jobs are all naturally safe to run again.

Technique 3: claim, then process

For batch jobs, mark each item as claimed in the same step as selecting it:

UPDATE emails
SET status = 'sending', claimed_at = now()
WHERE id IN (
  SELECT id FROM emails
  WHERE status = 'queued'
  ORDER BY id
  LIMIT 100
  FOR UPDATE SKIP LOCKED
)
RETURNING id, recipient;

Two overlapping runs each get different rows, and a re-run picks up only what's left.

External side effects

The idempotency key protects your database, but what about the payment provider or email API you call? Many such APIs accept their own idempotency key header. Pass your job key through so the provider can also drop duplicates:

requests.post(
    "https://api.payments.example/charges",
    headers={"Idempotency-Key": key},
    json={...},
)

If an API has no such option, record "sent" in your database before marking the job complete, and accept that a crash in between could still send twice. Design for the rare duplicate to be harmless.

Respond fast, work later

A long-running handler makes duplicates more likely, because callers time out. Accept the request, store the work, and return 202 Accepted quickly, then process it in a background worker. The idempotency key goes with it.

Test it

The simplest test: call the endpoint twice with the same payload, in parallel.

for i in 1 2; do
  curl -s -X POST localhost:5000/jobs/send-reminder \
    -H 'content-type: application/json' \
    -d '{"job_key":"test-1","user_id":42}' &
done; wait

One response should say "sent" and the other "duplicate".

Where retries come from

A hosted scheduler like delay.run calls your URL on a cron schedule or after a delay and retries failed jobs with backoff, logging each attempt. Retries are what make jobs reliable, and idempotent handlers are what make retries safe.

How to retry failed cron jobs (with exponential backoff, in Bash and Python)

delay.run — Wed, 28 Oct 2026 16:04:42 +0000

Cron has exactly one opinion about failure: it doesn't have one. If your job exits with an error at 02:00, cron writes nothing, retries nothing and tells nobody. The next attempt is whenever the schedule says, which might be tomorrow.

Most failures in scheduled jobs are temporary: a database restarting, an API returning 503, a network blip. A couple of retries with a pause in between turns most of those into non-events. Here's how to add retries properly, and where to stop.

Rule 1: decide what's worth retrying

Retrying makes sense for errors that might fix themselves:

timeouts and connection errors
HTTP 429 (too many requests), 502, 503, 504
"database is locked", "connection reset" and similar

Retrying does not help, and can make things worse, for:

HTTP 400, 401, 403, 404: the request is wrong and will stay wrong
validation errors, missing files, bad configuration
bugs in your code

Retrying a permanent error just delays the alert and adds load. Fail fast on those.

Rule 2: back off, and add jitter

Retrying immediately usually hits the same problem. Wait longer after each attempt: 5 seconds, then 10, then 20. This is exponential backoff. Add a little randomness (jitter) so that many jobs failing at once don't all retry at the same moment and knock the service over again.

Retries in Bash

A small function you can drop into any cron script:

#!/usr/bin/env bash
set -uo pipefail

retry() {
  local max=$1; shift
  local delay=5 attempt=1
  while true; do
    "$@" && return 0
    local code=$?
    if (( attempt >= max )); then
      echo "$(date -u +%FT%TZ) giving up after $attempt attempts (exit $code): $*" >&2
      return "$code"
    fi
    local sleep_for=$(( delay + RANDOM % delay ))
    echo "$(date -u +%FT%TZ) attempt $attempt failed (exit $code), retrying in ${sleep_for}s" >&2
    sleep "$sleep_for"
    attempt=$(( attempt + 1 ))
    delay=$(( delay * 2 ))
  done
}

retry 4 /usr/local/bin/export-orders.sh

30 2 * * * /usr/local/bin/export-with-retry.sh >> /var/log/export.log 2>&1

Four attempts with this delay pattern finish within a couple of minutes. Keep the total retry time well below the job's interval, or the next scheduled run will start while this one is still retrying. If that's possible, wrap the job in flock -n so runs can't overlap.

For HTTP calls, curl can do it

If the job is a single request, curl's built-in retries are enough:

curl -fsS --max-time 30 --retry 4 --retry-delay 5 --retry-max-time 120 \
  https://example.com/tasks/export

--retry only retries transient problems: timeouts and responses like 408, 429, 500, 502, 503 and 504. Recent curl versions also honour a Retry-After header. Avoid --retry-all-errors unless you really want to retry 4xx responses too.

Retries in Python

For jobs written in Python, the same logic with a permanent/transient split:

import random
import time

import requests

class Permanent(Exception):
    pass

def call_api():
    r = requests.post("https://api.example.com/export", timeout=30)
    if r.status_code in (429, 500, 502, 503, 504):
        r.raise_for_status()                     # transient: let retry handle it
    if r.status_code >= 400:
        raise Permanent(f"{r.status_code}: {r.text[:200]}")
    return r.json()

def retry(fn, attempts=4, base=5):
    for i in range(1, attempts + 1):
        try:
            return fn()
        except Permanent:
            raise
        except (requests.RequestException,) as e:
            if i == attempts:
                raise
            wait = base * 2 ** (i - 1) + random.uniform(0, base)
            print(f"attempt {i} failed ({e}); retrying in {wait:.0f}s", flush=True)
            time.sleep(wait)

if __name__ == "__main__":
    print(retry(call_api))

If you'd rather not write this yourself, the tenacity library provides decorators for the same patterns.

Rule 3: make the job safe to run twice

Retries mean the same work may run more than once. A request can succeed on the server and still time out on your side, so you retry something that already happened. Protect against that:

Use an idempotency key. Many payment and messaging APIs accept a key per operation and ignore duplicates. Derive it from the job and date, such as export-2026-10-28.
Record what's done. Write a marker (a database row, a file) when the work completes, and check it at the start.
Use upserts, not inserts. INSERT ... ON CONFLICT DO UPDATE survives a second run; a plain INSERT creates duplicates.

Rule 4: alert when retries run out

A retry loop hides problems by design, so you need to hear about the ones it can't fix. Two simple options.

Alert on final failure:

if ! retry 4 /usr/local/bin/export-orders.sh; then
  curl -fsS -X POST -H 'Content-Type: application/json' \
    -d '{"text":"export-orders failed after 4 attempts"}' "$SLACK_WEBHOOK_URL"
  exit 1
fi

Alert after N failed runs in a row, which avoids paging anyone for a single bad night:

STATE=/var/lib/export-orders.failures
if retry 4 /usr/local/bin/export-orders.sh; then
  rm -f "$STATE"
else
  n=$(( $(cat "$STATE" 2>/dev/null || echo 0) + 1 ))
  echo "$n" > "$STATE"
  (( n >= 3 )) && curl -fsS -X POST -d "{\"text\":\"export-orders failed $n runs in a row\"}" \
    -H 'Content-Type: application/json' "$SLACK_WEBHOOK_URL"
  exit 1
fi

Rule 5: keep failed work somewhere you can replay it

For jobs that process items (orders, emails, webhooks), don't let a failure lose the item. Write failed items to a "dead letter" table or file with the error, and add a small command to retry them once the cause is fixed. That turns an outage into a backlog instead of missing data.

Or let the scheduler handle it

If the job is an HTTP endpoint, a hosted scheduler can take over most of this. delay.run, for example, retries failed jobs with backoff (by default after 1 minute, 30 minutes and 3 hours) and moves them to a dead letter queue you can replay. Recurring crons aren't retried; instead it alerts by email, Slack or Discord after the number of failures in a row you choose, and again when the job recovers, with every run's response logged.

Summary

Cron never retries. Add retries in the job or use a scheduler that does.
Retry only transient errors, with exponential backoff and jitter.
Keep total retry time shorter than the schedule interval.
Make the job idempotent, because retries will repeat work.
Alert when retries are exhausted, ideally after a few failures in a row.
Save failed items so they can be replayed.

How to run cron jobs on serverless: Vercel, Cloudflare Workers and Netlify

delay.run — Wed, 28 Oct 2026 15:58:41 +0000

Serverless apps don't have a long-running machine where you can open a crontab. But you still need nightly cleanups, hourly syncs and Monday reports. Every major platform now has its own way to run a function on a schedule. They look similar, but they differ in configuration, security and what happens when a run fails.

Here's how to set up a scheduled job on Vercel, Cloudflare Workers and Netlify, and what to watch out for on each.

Vercel Cron Jobs

On Vercel, a cron job is a schedule that calls one of your routes. You declare it in vercel.json:

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

Then write the route as a normal function. In a Next.js App Router project:

// app/api/cron/cleanup/route.ts
export async function GET(request: Request) {
  const auth = request.headers.get('authorization');
  if (auth !== `Bearer ${process.env.CRON_SECRET}`) {
    return new Response('Unauthorized', { status: 401 });
  }

  const removed = await deleteExpiredSessions();
  return Response.json({ removed });
}

Things to know:

Secure it with CRON_SECRET. Add an environment variable called CRON_SECRET to the project, and Vercel sends it as a Bearer token in the Authorization header on cron invocations. Without the check, anyone who finds the path can run your job.
Schedules are in UTC. 0 3 * * * is 3:00 UTC.
Production only. Crons run against the production deployment, not previews.
Plan limits apply. The number of cron jobs and how precisely they fire depend on your plan. Check the current limits before you design around a schedule like every five minutes.
It's a normal function invocation. The usual function duration limits apply, and a failed run isn't automatically retried.

Cloudflare Workers Cron Triggers

On Cloudflare, cron triggers call a scheduled handler in your Worker rather than an HTTP route. Configure them in wrangler.toml:

name = "nightly-jobs"
main = "src/index.ts"
compatibility_date = "2026-01-01"

[triggers]
crons = ["0 3 * * *", "*/30 * * * *"]

Then export a scheduled handler:

export default {
  async scheduled(controller: ScheduledController, env: Env, ctx: ExecutionContext) {
    switch (controller.cron) {
      case '0 3 * * *':
        ctx.waitUntil(runNightlyCleanup(env));
        break;
      case '*/30 * * * *':
        ctx.waitUntil(syncInventory(env));
        break;
    }
  },
};

Things to know:

No public URL. The handler isn't reachable over HTTP, so there's nothing to secure with a secret. That's a nice property.
controller.cron tells you which schedule fired, so one Worker can serve several schedules.
Schedules are in UTC.
Test locally with npx wrangler dev --test-scheduled. The dev server then exposes a route you can request to trigger the handler; the wrangler output shows the URL to use.
Use ctx.waitUntil() for async work so the runtime doesn't end the invocation early.
Past runs appear in the Worker's logs and metrics in the dashboard. Check there first when a job seems not to run.

Netlify Scheduled Functions

Netlify lets you attach a schedule to a function in code:

// netlify/functions/daily-digest.mts
import type { Config } from '@netlify/functions';

export default async (req: Request) => {
  await sendDailyDigest();
  return new Response('ok');
};

export const config: Config = {
  schedule: '0 8 * * *',
};

Shortcuts like @hourly and @daily are also accepted. Like the others, schedules run in UTC, they only run on published deploys, and scheduled functions have a shorter execution limit than regular ones. For longer work, have the scheduled function hand off to a background function or a queue.

The common limits

All three platforms solve "run this code on a schedule". None of them is a full job system. Plan for these gaps:

1. UTC only. If a job must run at 9:00 in a specific time zone all year, either accept a DST shift twice a year, or schedule hourly and check the local hour inside the function:

const hour = Number(new Intl.DateTimeFormat('en-GB', {
  hour: 'numeric', hourCycle: 'h23', timeZone: 'Europe/Berlin',
}).format(new Date()));

if (hour !== 9) return new Response('skip');

2. Timeouts. Scheduled functions share the platform's execution limits. Process work in batches, save a cursor, and pick up where you left off on the next run.

3. No retries. If the run throws, you usually find out later, if at all. Catch errors, log them, and send yourself an alert:

try {
  await syncInventory(env);
} catch (err) {
  await fetch(env.ALERT_WEBHOOK_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text: `syncInventory failed: ${String(err)}` }),
  });
  throw err;
}

4. Overlap. If a run takes longer than the interval, two can run at once. Use a lock (a row in your database, a key in KV with an expiry) or make the job idempotent.

5. Vendor lock-in. Your schedules live in platform config. Moving hosts means rewriting them.

When to use an external scheduler instead

If your job is already an HTTP endpoint, you can keep the schedule outside your hosting platform entirely. A hosted scheduler calls the endpoint on a cron, so the same setup keeps working on Vercel, Cloudflare, Render, Fly or your own servers.

delay.run is one option built for this: it calls your URL on a standard five-field cron or after a delay, logs every run with its request, response and latency, retries failed one-off jobs with backoff, and alerts by email, Slack or Discord when a cron fails several times in a row. Requests are HMAC-signed, so your endpoint can verify they came from the scheduler.

Which should you pick?

One or two simple jobs on Vercel or Netlify: use the built-in cron. Add the auth check and error alerts.
Cloudflare Workers: Cron Triggers are excellent, with no public URL and multiple schedules per Worker.
Jobs that must not fail silently, or you're on several platforms: use an external scheduler with logs, retries and alerts, and keep your endpoints portable.

Whichever you choose, write the job so that it can safely run twice, finish within the time limit, and tell you when it fails. That covers most of what can go wrong with scheduled code on serverless.

How to schedule an HTTP request (call a URL or webhook on a schedule)

delay.run — Wed, 28 Oct 2026 15:52:11 +0000

A surprising number of background jobs boil down to one thing: call this URL every hour. Refresh a cache, sync orders from an API, send a daily digest, ping a webhook. Your app already has the logic behind an endpoint. You just need something to hit it on schedule.

This guide covers three ways to do that, the curl flags that make the difference between a reliable job and a silent one, and how to protect the endpoint so only your scheduler can trigger it.

Option 1: crontab and curl

If you have a Linux server, this is the quickest route. Run crontab -e and add a line:

*/15 * * * * curl -fsS --max-time 30 https://example.com/tasks/sync >> /var/log/sync.log 2>&1

That calls the URL every 15 minutes. The flags matter more than they look:

-f makes curl exit with an error on HTTP 4xx and 5xx responses. Without it, a 500 from your app counts as success.
-sS hides the progress bar but still prints errors.
--max-time 30 stops a hung request from piling up behind the next run.
>> ... 2>&1 keeps a log, so you can see what happened at 3 am.

Sending a POST with JSON and a secret

Most task endpoints should reject anonymous requests. Keep the token in a file readable only by the cron user, not in the crontab itself:

#!/usr/bin/env bash
# /usr/local/bin/call-sync.sh
set -euo pipefail
TOKEN="$(cat /etc/myapp/cron-token)"

curl -fsS --max-time 30 \
  -X POST https://example.com/tasks/sync \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"source":"cron"}'

*/15 * * * * /usr/local/bin/call-sync.sh >> /var/log/sync.log 2>&1

Putting the request in a script also avoids cron's % problem. Inside a crontab, % means newline, so a JSON body or a date +%F in the line breaks in confusing ways unless you escape it as \%.

Retrying transient failures

curl can retry on its own:

curl -fsS --max-time 30 --retry 3 --retry-delay 10 https://example.com/tasks/sync

--retry covers timeouts and responses like 429, 502, 503 and 504. Only use it if the endpoint is safe to call twice.

Option 2: a systemd timer

On systemd-based servers, timers are a more structured alternative to cron. You get logs in the journal and the option to catch up on missed runs.

# /etc/systemd/system/sync.service
[Unit]
Description=Call the sync endpoint

[Service]
Type=oneshot
ExecStart=/usr/local/bin/call-sync.sh

# /etc/systemd/system/sync.timer
[Unit]
Description=Run sync every 15 minutes

[Timer]
OnCalendar=*:0/15
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now sync.timer
systemctl list-timers sync.timer
journalctl -u sync.service --since today

Persistent=true runs the job once at boot if the machine was off when it was due.

Option 3: a hosted HTTP scheduler

Both options above need a server that's always on, and both fail quietly when that server goes away. If the job is only an HTTP call, a hosted scheduler removes the server from the picture. You give it a URL and a schedule, and it makes the request.

delay.run works this way: one API call creates a recurring cron (standard five-field syntax, as often as every minute) or a one-off job that runs right away or after a delay of up to 24 hours. Every run is logged with the request, response body, status code and latency, and you can get alerts by email, Slack or Discord when a cron fails several times in a row. It's plain HTTP with no SDK, so it works with any language or framework.

The main thing to compare between hosted options is what you can see after the fact: whether you get the response body of a failed run, and whether anything tells you when a schedule keeps failing.

Secure the endpoint

A task URL that anyone can trigger is an invitation for abuse. Pick one of these:

A shared secret in a header. Simple and good enough for most internal jobs:

// Express
app.post('/tasks/sync', (req, res) => {
  if (req.get('authorization') !== `Bearer ${process.env.CRON_TOKEN}`) {
    return res.status(401).end();
  }
  // ... do the work ...
  res.json({ ok: true });
});

A signed request. Better when the scheduler supports it. The sender computes an HMAC of the body and a timestamp with a shared key, and your endpoint recomputes it. The timestamp stops someone replaying an old request:

import crypto from 'node:crypto';

function verify(rawBody, timestamp, signature, secret) {
  if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return false;  // 5 minutes
  const expected = crypto
    .createHmac('sha256', secret)
    .update(`${timestamp}.${rawBody}`)
    .digest('hex');
  return signature.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

The exact header names and the string that gets signed depend on the scheduler, so check its docs. Always verify against the raw request body, before JSON parsing changes it.

Design the endpoint for scheduled calls

A few habits make scheduled HTTP jobs much easier to live with:

Return a real status code. 200 when the work succeeded, 5xx when it didn't. Schedulers and curl -f rely on it.
Respond with a short summary. {"synced": 42} in the response body shows up in logs and makes "did it actually do anything?" easy to answer.
Be idempotent. Retries, overlaps and manual re-runs will happen. Running the same job twice shouldn't send two emails or charge a card twice.
Keep it short or hand off. If the work takes minutes, accept the request, queue the work, and return quickly. Long requests hit timeouts on proxies and serverless platforms.

Quick checklist

curl uses -f and --max-time
secrets live in a file or environment variable, not in the crontab
the endpoint rejects requests without the secret or a valid signature
the endpoint returns 5xx on failure
there's a log of every run, and something alerts you when runs keep failing

Get those right and "call this URL every 15 minutes" becomes a job you can forget about, in the good way.

Cron job timezone problems: how to run cron in a specific time zone (and survive DST)

delay.run — Wed, 28 Oct 2026 15:46:09 +0000

You set a job for 0 9 * * *. It runs at 10:00. Or at 4:00. Or it ran fine all summer and has been an hour late since the clocks changed. Almost every "cron runs at the wrong time" problem comes down to one fact: cron doesn't know what time zone you meant. It uses whatever the system it runs on is set to.

Here's how to find out which time zone your cron uses, how to change it per job, and how to avoid the daylight saving time traps.

Step 1: Find out what time zone cron is using

On most Linux servers, cron uses the system time zone. Check it:

timedatectl

               Local time: Wed 2026-10-28 15:00:12 UTC
           Universal time: Wed 2026-10-28 15:00:12 UTC
                Time zone: Etc/UTC (UTC, +0000)

Cloud images default to UTC almost everywhere. If you developed on a laptop set to your local time, that's the source of the offset.

Note that cron reads the time zone when it starts. If you change the system time zone, restart the cron service so it picks up the change:

sudo timedatectl set-timezone Europe/Berlin
sudo systemctl restart cron      # "crond" on RHEL, Fedora and similar

Changing the whole server's time zone affects logs and every other job too. Usually it's better to leave the server on UTC and handle time zones per job.

Step 2: Set a time zone for a single crontab

Some cron implementations support a CRON_TZ variable at the top of a crontab:

CRON_TZ=Europe/Berlin
0 9 * * 1-5 /usr/local/bin/morning-report.sh

This works in cronie, the cron used by RHEL, Fedora, CentOS and Arch. Support in other implementations varies, so check man 5 crontab on your system and search for CRON_TZ. If it's not mentioned, it's probably ignored without any warning.

Don't confuse it with TZ=... in the crontab. TZ sets the time zone for the command (so date inside your script prints local time), but it doesn't change when cron fires the job.

Step 3: The portable trick: run hourly and check the local hour

If you can't rely on CRON_TZ, schedule the job every hour and let it decide whether this is the right hour in the time zone you care about:

0 * * * * [ "$(TZ=America/New_York date +\%H)" = 09 ] && /usr/local/bin/morning-report.sh

This runs at 9:00 New York time all year, through both daylight saving changes, on any cron implementation. The cost is 23 no-op wake-ups a day, which is nothing. Remember to escape % as \% inside a crontab.

Step 4: Understand what DST does to your schedule

Daylight saving time creates one hour that doesn't exist (spring forward) and one hour that happens twice (fall back). Jobs scheduled inside those hours behave differently depending on the cron implementation:

A job at 2:30 am on the spring-forward night may be skipped, or run at 3:00.
A job at 1:30 am on the fall-back night may run twice.

Classic Vixie-derived cron has special handling for small clock changes to reduce this, but don't depend on details that differ across versions. The simple rules:

Avoid scheduling local-time jobs between 1:00 and 3:00 am.
If a job must run exactly once a day, make it idempotent: check whether today's run already happened before doing the work.
If the time doesn't matter to humans (backups, cleanup), schedule in UTC, which has no DST.

Time zones in other schedulers

systemd timers accept a time zone directly in OnCalendar:

[Timer]
OnCalendar=Mon..Fri *-*-* 09:00:00 Europe/Berlin
Persistent=true

Check how systemd reads it with:

systemd-analyze calendar "Mon..Fri *-*-* 09:00:00 Europe/Berlin"

It prints the next elapse time in both your local time and UTC.

Kubernetes CronJobs have a timeZone field (stable since Kubernetes 1.27):

apiVersion: batch/v1
kind: CronJob
metadata:
  name: morning-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "Europe/Berlin"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: report
              image: example/report:latest

Without timeZone, the schedule follows the time zone of the kube-controller-manager, which is usually UTC.

GitHub Actions, Vercel Cron Jobs and Cloudflare Workers Cron Triggers evaluate schedules in UTC. Convert your local time to UTC, and remember the offset changes with DST. A job that must run at 9:00 local time year-round needs either two schedules you switch twice a year, or the "run hourly and check" approach inside the job.

Step 5: Log the time zone with every run

When debugging, print both local and UTC time at the start of the job. It ends arguments about what time it "really" ran:

#!/usr/bin/env bash
echo "start local=$(date '+%F %T %Z') utc=$(date -u '+%F %T')"
# ... the actual work ...

0 9 * * * /usr/local/bin/job.sh >> /var/log/job.log 2>&1

Converting a local time to UTC quickly

GNU date can do the conversion for you:

date -u -d 'TZ="Europe/Berlin" 09:00 next Monday' '+%H:%M UTC'

Run it once for a date in summer and once in winter to see both offsets.

A cleaner option for HTTP jobs

If the job is a call to one of your endpoints, it doesn't need to live on a server with a system clock you have to think about. delay.run runs standard five-field cron schedules against your URL, retries one-off jobs that fail, and logs each run's request, response and latency, which makes it easy to see exactly when a run happened.

Summary

Cron uses the system time zone, which on servers is usually UTC.
CRON_TZ works in some implementations, not all. Check man 5 crontab.
TZ= changes the command's clock, not the schedule.
The hourly-check trick works everywhere and handles DST.
systemd timers and Kubernetes CronJobs let you set a time zone explicitly.
Keep local-time jobs out of the 1-3 am window, and make daily jobs safe to run twice.

Cron expression for every Monday at 9am (and other weekly schedules)

delay.run — Wed, 28 Oct 2026 15:39:57 +0000

Short answer: the cron expression for every Monday at 9:00 am is:

0 9 * * 1

That's minute 0, hour 9, any day of the month, any month, day of week 1 (Monday). The rest of this post covers the variations people usually need next, and a few traps in the day-of-week field that make jobs run on the wrong day.

Reading the five fields

â”Œâ”€â”€â”€â”€â”€â”€â”€â”€ minute        (0-59)
â”‚ â”Œâ”€â”€â”€â”€â”€â”€ hour          (0-23)
â”‚ â”‚ â”Œâ”€â”€â”€â”€ day of month  (1-31)
â”‚ â”‚ â”‚ â”Œâ”€â”€ month         (1-12 or JAN-DEC)
â”‚ â”‚ â”‚ â”‚ â”Œ day of week   (0-7 or SUN-SAT, 0 and 7 are both Sunday)
â”‚ â”‚ â”‚ â”‚ â”‚
0 9 * * 1

Hours use a 24-hour clock, so 9 pm is 21. Most cron implementations accept three-letter names, so 0 9 * * MON means the same thing and is easier to read in a crontab you'll revisit next year.

Weekly schedules you can copy

Schedule	Expression
Every Monday at 9:00	`0 9 * * 1`
Every Monday at 9:30	`30 9 * * 1`
Every Monday at 9 am and 5 pm	`0 9,17 * * 1`
Every weekday (Mon-Fri) at 9:00	`0 9 * * 1-5`
Monday, Wednesday and Friday at 9:00	`0 9 * * 1,3,5`
Every Sunday at midnight	`0 0 * * 0`
Every Saturday and Sunday at 10:00	`0 10 * * 6,0`
Every 15 minutes on Mondays, 9 to 5	`/15 9-16 * 1`
Every Monday at 9:00, January to June	`0 9 * 1-6 1`

Note the 9-to-5 example uses 9-16 for the hour. */15 9-17 would also fire at 17:00, 17:15, 17:30 and 17:45.

Trap 1: "first Monday of the month" doesn't work the obvious way

This looks right, but isn't:

0 9 1-7 * 1     # NOT "first Monday"

When both day-of-month and day-of-week are restricted (neither is *), standard cron runs the job when either matches. So this runs on days 1 to 7 of every month and on every Monday. That's up to 11 runs a month instead of one.

The reliable fix is to schedule on days 1 to 7 and let the command check the weekday:

0 9 1-7 * * [ "$(date +\%u)" = 1 ] && /usr/local/bin/monthly-report.sh

date +%u prints 1 for Monday through 7 for Sunday. The % has to be escaped as \% in a crontab, because cron treats an unescaped % as a newline. Forgetting that is a classic reason a job "never runs".

The same pattern works for "last Friday of the month":

0 9 22-31 * * [ "$(date +\%u)" = 5 ] && [ "$(date -d '+7 days' +\%m)" != "$(date +\%m)" ] && /path/to/job.sh

The second test checks that a week from today falls in the next month, which is only true for the last Friday. date -d is GNU syntax; on macOS use date -v+7d.

Trap 2: Sunday is 0, and also 7

Most cron versions accept both 0 and 7 for Sunday. A range like 1-7 therefore means Monday to Sunday, every day. If you want the weekend, write 6,0 or SAT,SUN, not 6-7 unless you've checked your implementation supports it.

Trap 3: other schedulers use different formats

The five-field format above is standard Unix cron, also used by most hosted schedulers, GitHub Actions and Kubernetes CronJobs. Some systems differ:

Quartz and Spring use six or seven fields, starting with seconds, and need ? in one of the day fields:

0 0 9 ? * MON        # second minute hour day-of-month month day-of-week

Also note that in Quartz, day-of-week runs 1 to 7 starting with Sunday, so 2 is Monday. Copying 0 9 * * 1 into Quartz-style config won't do what you expect.

AWS EventBridge uses six fields with a year at the end, and also requires ?:

cron(0 9 ? * MON *)

If a scheduler rejects your expression, count the fields first. That's the cause most of the time.

Trap 4: 9 am in which time zone?

Cron runs in the time zone of the machine or service running it. On a cloud server that's very often UTC, so 0 9 * * 1 fires at 9:00 UTC, which may be 10:00 or 11:00 for your team in Europe, or the middle of the night in Asia.

Check what the server thinks the time is:

timedatectl          # on systemd-based Linux
date

Either convert your schedule to UTC, or use a scheduler that lets you set a time zone per job. If you convert, remember that daylight saving time shifts the offset twice a year.

Test the schedule before you rely on it

A weekly job gives you one chance a week to notice it's wrong. Before saving it:

Paste the expression into a cron expression explainer and read the next few run times it lists.
Temporarily change it to run a few minutes from now, check it works, then set the real schedule.
Log the output so a failure isn't silent:

0 9 * * 1 /usr/local/bin/weekly-report.sh >> /var/log/weekly-report.log 2>&1

Running it without a server

If the job is really "call this URL every Monday at 9", you don't need a machine with a crontab at all. A hosted scheduler like delay.run takes the same five-field expression, calls your endpoint on schedule, and logs each run with its status code and response, so you can see last Monday's result instead of guessing.

Whichever route you take, 0 9 * * 1 is the line you need. Just double-check the time zone and the day-of-month field, and it will fire once a week, exactly when you expect.

Cron job not running? A step-by-step checklist (including “it works when I run it manually”)

delay.run — Tue, 27 Oct 2026 09:20:56 +0000

You added a line to your crontab, waited, and nothing happened. Or the script works perfectly when you run it in your terminal, but cron never seems to run it. This is one of the most common Linux problems, and it nearly always comes down to a short list of causes. Work through them in this order and you will find it.

1. Is the cron daemon actually running?

Start with the obvious. On Debian and Ubuntu the service is called cron; on RHEL, Fedora, Rocky and Alma it is crond.

systemctl status cron      # Debian / Ubuntu
systemctl status crond     # RHEL family

If it is inactive, start and enable it:

sudo systemctl enable --now cron

Inside Docker containers there is usually no cron daemon at all unless you install and start one yourself. A crontab file in an image does nothing on its own.

2. Did cron try to run the job?

Cron logs every job it starts. Check the log before you change anything else, because it tells you whether the problem is the schedule or the command.

grep CRON /var/log/syslog          # Debian / Ubuntu
sudo tail -f /var/log/cron         # RHEL family
journalctl -u cron --since "1 hour ago"

No line for your job at the expected time: the schedule or the crontab file is wrong (steps 3 and 4).
A line saying CMD (...) but nothing happened: cron ran it and the command failed (steps 5 to 8).

3. Check the schedule syntax

A standard crontab line has five time fields, then the command:

# m   h   dom mon dow   command
*/5   *   *   *   *     /home/app/bin/sync.sh

Common mistakes:

Six fields. Standard cron has no seconds field. 0 */5 * * * * is valid in Spring or Quartz, but in crontab the sixth value becomes part of the command.
Day-of-month and day-of-week both set. 0 9 1 * 1 runs on the 1st of the month and on every Monday, not only on Mondays that fall on the 1st.
Expecting */7 in the minute field to mean "every 7 minutes forever". It restarts every hour, so you get :00, :07 … :56, then :00 again.

Paste the expression into a cron explainer if you are unsure, and confirm it says what you think.

4. Check which crontab you edited

There are several places cron reads from, and they use different formats:

crontab -e edits your user's crontab. No user column.
/etc/crontab and files in /etc/cron.d/ have an extra user column after the five time fields: 0 3 * * * root /usr/local/bin/backup.sh. Leave it out and the job silently fails.
Files in /etc/cron.d/ are ignored if the file name contains a dot (on Debian-based systems), so backup.cron is skipped while backup works. They also need to be owned by root and not group- or world-writable.
sudo crontab -e edits root's crontab, which is a different file from yours. Run crontab -l and sudo crontab -l to see both.

Also make sure the file ends with a newline. Some cron implementations ignore the last line if it doesn't.

5. “It runs manually but not in cron”: the environment

This is the big one. When you run a script in your terminal, you have your shell profile, your PATH, your virtualenv and your current directory. Cron has almost none of that. Its PATH is typically just /usr/bin:/bin, its shell is /bin/sh, and it starts in your home directory.

So a script that calls node, python3 from a virtualenv, aws, docker or anything in /usr/local/bin may simply not find the binary.

Fixes, in order of preference:

# Use absolute paths everywhere
*/5 * * * * /usr/local/bin/node /home/app/jobs/sync.js

# Or set PATH at the top of the crontab
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

If the script needs environment variables (API keys, DATABASE_URL), cron will not load them from .bashrc. Source a file explicitly or set them in the script.

To reproduce cron's environment in your terminal and see the real error:

env -i SHELL=/bin/sh PATH=/usr/bin:/bin HOME="$HOME" /bin/sh -c '/home/app/bin/sync.sh'

6. Relative paths and the working directory

A script that reads ./config.yml or writes logs/out.txt works from the project folder but not from cron, which starts in $HOME. Either cd first or use absolute paths:

0 * * * * cd /home/app && ./bin/report.sh

7. Percent signs and permissions

In a crontab line, % means "newline" and everything after the first one is sent to the command as standard input. This breaks date +%Y-%m-%d in a surprising way. Escape it as \%:

0 2 * * * /usr/bin/tar czf /backups/site-$(date +\%F).tgz /var/www

Then check the script itself: is it executable (chmod +x), does it start with a correct shebang (#!/usr/bin/env bash), and can the cron user read every file it touches?

8. Capture the output

By default, cron emails output to the local user, which on most servers means it disappears. Redirect it to a file so you can see what happened:

*/5 * * * * /home/app/bin/sync.sh >> /home/app/logs/sync.log 2>&1

The 2>&1 matters: most errors go to standard error. If you have a working mail setup, MAILTO=you@example.com at the top of the crontab sends output by email instead.

9. Time zone and reboot surprises

Cron uses the server's time zone. A job set for 0 9 * * * on a server in UTC runs at 9:00 UTC, not 9:00 where you are. Check with timedatectl. Some cron versions support CRON_TZ=Europe/Berlin at the top of the file.

@reboot jobs run when the cron daemon starts, which can be before the network or your database is ready. Add a short wait or a retry loop in the script.

The real problem: cron fails silently

Once your job works, there is a second issue: the next time it breaks, nothing will tell you. A crontab that stops gives no output and no error. The usual ways to cover that are:

Log to a file and have something watch the file or the job's last run time.
Use a "dead man's switch" style monitor that alerts when a job fails to check in.
Move the schedule off the server entirely and have a hosted scheduler call an HTTP endpoint in your app, so retries, run history and alerts live in one place.

If you go the HTTP route, delay.run is one option: it calls your URL on a cron schedule, logs each response and alerts you by email, Slack or Discord when runs keep failing.

Whichever you choose, the checklist above will get the job running. Making sure you hear about it next time it stops is what saves you the Monday-morning surprise.

DEV Community: delay.run

How to verify HMAC-SHA256 signed webhooks in Node and Python

How HMAC signing works

Rule 1: use the raw body

Rule 2: compare in constant time

Rule 3: check the timestamp

Node.js (Express)

Python (Flask)

Test it locally

Rotating secrets

Combine with idempotency

Signed scheduled calls

Related reading

Make scheduled job handlers idempotent: safe to run twice

Why duplicates are unavoidable

Technique 1: an idempotency key

Choosing the key

Technique 2: make the work itself naturally idempotent

Technique 3: claim, then process

External side effects

Respond fast, work later

Test it

Where retries come from

Related reading

How to retry failed cron jobs (with exponential backoff, in Bash and Python)

Rule 1: decide what's worth retrying

Rule 2: back off, and add jitter

Retries in Bash

For HTTP calls, curl can do it

Retries in Python

Rule 3: make the job safe to run twice

Rule 4: alert when retries run out

Rule 5: keep failed work somewhere you can replay it

Or let the scheduler handle it

Summary

Related reading

How to run cron jobs on serverless: Vercel, Cloudflare Workers and Netlify

Vercel Cron Jobs

Cloudflare Workers Cron Triggers

Netlify Scheduled Functions

The common limits

When to use an external scheduler instead

Which should you pick?

Related reading

How to schedule an HTTP request (call a URL or webhook on a schedule)

Option 1: crontab and curl

Sending a POST with JSON and a secret

Retrying transient failures

Option 2: a systemd timer

Option 3: a hosted HTTP scheduler

Secure the endpoint

Design the endpoint for scheduled calls

Quick checklist

Related reading

Cron job timezone problems: how to run cron in a specific time zone (and survive DST)

Step 1: Find out what time zone cron is using

Step 2: Set a time zone for a single crontab

Step 3: The portable trick: run hourly and check the local hour

Step 4: Understand what DST does to your schedule

Time zones in other schedulers

Step 5: Log the time zone with every run

Converting a local time to UTC quickly

A cleaner option for HTTP jobs

Summary

Related reading

Cron expression for every Monday at 9am (and other weekly schedules)

Reading the five fields

Weekly schedules you can copy

Trap 1: "first Monday of the month" doesn't work the obvious way

Trap 2: Sunday is 0, and also 7

Trap 3: other schedulers use different formats

Trap 4: 9 am in which time zone?

Test the schedule before you rely on it

Running it without a server

Related reading

Cron job not running? A step-by-step checklist (including “it works when I run it manually”)

1. Is the cron daemon actually running?

2. Did cron try to run the job?

3. Check the schedule syntax

4. Check which crontab you edited