Hosted cron for scheduled webhooks without babysitting crontab.
vøiddo Cron is the narrow version of a problem most small products keep rebuilding. You need a recurring HTTP call, retries when the endpoint flakes, logs when it fails, and email alerts before users notice. You do not need shell commands, systemd spelunking, or another VPS-specific cron ritual.
This page is the owned substitute route for the product whenever HN or Dev.to are session-gated, manual-safe, or simply not worth waiting on. The product still needs a clean explanation that points directly at the live landing, pricing, and checkout host.
Use it for health checks, recurring sync triggers, scheduled report pushes, webhook fan-out jobs, or any product that needs a few reliable HTTP calls but does not deserve bespoke cron plumbing on every box.
What you actually get
| part | what it does | why it matters |
|---|---|---|
| free tier | 3 scheduled webhook jobs for proving the workflow on a live project. | You can validate whether the product fits before paying for it. |
| pro tier | $9 per month for 100 jobs, retry policy, structured execution logs, failure email alerts, and the full REST API. | Once the project is real, you stop babysitting crontab and start seeing failures in one place. |
| scope guard | Webhook-only. No shell commands. No pretend DevOps platform wrapper. | The product stays narrow enough to stay dependable for the exact use case it claims. |
When this beats Linux cron
Multiple small products, same recurring job pattern
- health pings that should alert you before the customer does
- scheduled report or digest triggers that only need an HTTP endpoint
- simple sync jobs between services you already run
- operators who want retries and logs without SSHing into another VPS
Shell execution, sub-minute timing, or full workflow orchestration
- jobs that must run arbitrary shell commands on your own host
- workloads that need precision tighter than the 30-second runner cadence
- teams that already have a larger queueing or orchestration layer and should keep it
- buyers expecting a generic automation platform instead of a cron-for-webhooks tool
Why the free and paid split is this small
The point is not to invent a pricing ladder. The point is to make the first decision obvious. Three jobs is enough to test real behavior. One paid plan is enough when the same project needs more than a few scheduled calls, plus logs, retries, and email alerts. The product is priced like a utility because that is what it is.
vøiddo Cron is not serverless workflows or automation for everything. It is a narrow hosted cron service for webhook jobs. That smaller promise is the reason it can stay cheap and legible.
What to inspect before you buy
FAQ
Does vøiddo Cron execute shell commands?
No. It is intentionally webhook-only. If you need shell execution, keep that logic on your own infrastructure and expose the HTTP endpoint you actually want to schedule.
How precise is the timing?
The runner polls every 30 seconds, so scheduling precision is about 30 seconds. That is fine for most report, sync, and health-ping jobs, but not for sub-minute trading or other tight loops.
What does Pro unlock?
Pro lifts the account from 3 jobs to 100, adds retry policy, execution logs, failure email alerts, and the full REST API for programmatic job CRUD.
Why publish this article instead of waiting on HN or Dev.to?
Because some public channels are gated by session access, account trust, or manual-safe posting rules. The product still needs a clean owned route that search, internal cross-links, and future outreach can point at immediately.
Need the smallest cron layer that still feels real?
Open the landing if you want to see the scope first, or go straight to the live checkout if you already know you want the 100-job tier. The free path is there for proof. The paid step is there when the proof becomes real work.