How to Schedule HTTP Requests Without Managing Cron Jobs
If you’ve ever needed to send an HTTP request at a specific time — a reminder email 30 minutes after signup, a webhook at midnight, or a recurring API call every hour — you’ve probably reached for cron jobs, task queues, or cloud schedulers.
They all work. They’re also all more infrastructure than you need.
The Problem With Traditional Approaches
Cron jobs require a server that’s always running. You need to manage uptime, handle failures, deal with overlapping executions, and monitor logs. For a simple “send this request later,” that’s a lot of overhead.
Task queues (Redis + Celery, Bull, etc.) are even heavier. You’re managing a message broker, worker processes, serialization formats, and dead letter queues. Great for complex workflows. Overkill for “POST to this URL in 5 minutes.”
Cloud schedulers (AWS EventBridge, Google Cloud Scheduler) work well but require you to be on that cloud platform, configure IAM roles, and navigate console UIs. Vendor lock-in for a simple HTTP call.
A Simpler Way: Prefix Your URL
What if scheduling an HTTP request was as simple as adding a query parameter?
# Send a POST request in 60 seconds
curl -X POST "https://zeplo.to/https://api.yourapp.com/send-email?_delay=60&_token=YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"to": "user@example.com", "template": "welcome"}'
That’s it. No infrastructure, no workers, no cron syntax. Zeplo receives your request, holds it for 60 seconds, then forwards it to your endpoint with the exact headers and body you specified.
Recurring Schedules With Cron Syntax
Need something recurring? Use the _cron parameter:
# Send a Slack reminder every weekday at 9am UTC
curl -X POST "https://zeplo.to/https://hooks.slack.com/services/YOUR/WEBHOOK/URL?_cron=0|9|*|*|1-5&_token=YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"text": "Daily standup in 15 minutes!"}'
The cron syntax uses pipes (|) instead of spaces (since it’s in a URL), but otherwise it’s standard cron: minute|hour|day|month|weekday.
Delayed Webhooks for Transactional Flows
This pattern is especially powerful for transactional workflows:
# Send a review request 48 hours after purchase
curl -X POST "https://zeplo.to/https://api.yourapp.com/review-request?_delay=172800&_token=YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"order_id": "ord_12345", "customer_email": "buyer@example.com"}'
# Delete user data 30 days after account closure (GDPR compliance)
curl -X POST "https://zeplo.to/https://api.yourapp.com/delete-user-data?_delay=2592000&_token=YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"user_id": "usr_67890"}'
Built-in Retry on Failure
Every scheduled request automatically retries on failure. Configure the retry behavior:
# Retry up to 5 times with exponential backoff
curl -X POST "https://zeplo.to/https://api.yourapp.com/critical-task?_delay=3600&_retry=5&_token=YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"task": "process_payment"}'
If your endpoint returns a 5xx error or times out, Zeplo retries with increasing delays. No dead letter queue configuration needed.
When to Use This vs. a Full Queue
Use Zeplo when: - You need to delay or schedule HTTP requests - You want retry logic without managing a queue - You’re building webhooks, reminders, or transactional emails - You want to add queuing to an existing API without changing architecture
Use a full queue (SQS, RabbitMQ) when: - You need complex routing, fan-out, or pub/sub patterns - You’re processing millions of messages per second - You need guaranteed ordering (FIFO) - You’re already deep in a cloud ecosystem
Getting Started
- Sign up for free — 500 requests/month included
- Get your API token from the dashboard
- Prefix any URL with
https://zeplo.to/and add?_token=YOUR_TOKEN
No SDK, no library, no configuration files. If you can make an HTTP request, you can use Zeplo.
Zeplo is a managed HTTP request queue. Delay, retry, and schedule any HTTP request with a simple URL prefix. Try it free →