If you already understand server CRON, hosted Web CRON is a short step sideways. The idea is the same, run something on a schedule, but the scheduler no longer lives on the machine doing the work. Instead, a hosted service keeps the clock and, when a schedule fires, sends an HTTP request to an endpoint you expose. Your application does the actual task and answers with a status. This page walks through that lifecycle one stage at a time, marks what your application still owns, and flags which details to confirm against the official source before you depend on them.
One distinction runs through everything below. The generic mechanics of scheduled HTTP requests are stable and worth understanding on their own. The product-specific behavior of Web CRON by ostr.io is stated separately, drawn from public evidence dated on this page, and should be refreshed before you rely on it.
Timing on one side, your task on the other
Hosted Web CRON separates timing from application code. You define when work should run, and the scheduler calls an endpoint that performs it. What does not move is ownership of the task itself: your application still owns the task logic, the permission checks, the idempotency, and the response it returns.
That split is the whole mental model. As a rule, a scheduled HTTP task is easier to operate when the endpoint can be called more than once without harm and returns a clear success or failure response. Build it that way and the scheduler’s job stays simple: fire on time, read the result, and surface it.
Picture a nightly job that rebuilds a search index. The schedule says 02:00, the scheduler calls a route like /tasks/rebuild-index, your code does the work, and it returns a 200 or an error status. None of the index logic lives in the scheduler, which is exactly the point: the timing is hosted, the work stays in your application.
What the scheduler calls: an HTTP endpoint
The target is an endpoint you already control. Public evidence supports the statement that Web CRON by ostr.io triggers server tasks over HTTP, so the unit of work is an ordinary request to a URL that runs your task. [ostr.io/info/web-cron, accessed ] Beyond that, this page does not assert protocol specifics the public documentation does not state. Treat transport security as something to confirm against the official source and to enforce on your own endpoint.
Think of the endpoint as a pattern rather than a product screen: a route that does one job, validates its caller, and reports back. It is worth being clear about what the scheduler does not do. It does not write your task, and it cannot know a run succeeded unless your endpoint says so through its status code. A task that returns 200 while swallowing an error will look healthy from the outside, which is the failure mode most worth designing against. The HTTP task calls page covers how the request behaves and what the scheduler expects in the response.
When it runs: CRON-style timing
Scheduling uses a familiar shape. Public evidence supports task rules similar to classic Linux CRON, which means the five-field expressions you have written for a crontab translate directly to expressing a recurring schedule here. [ostr.io/info/web-cron, accessed ]If you can already say “every night at 02:15” or “every fifteen minutes” in CRON syntax, you can say it for a hosted run.
What the public documentation does not pin down is the exact parser behavior, the default timezone, and any minimum interval or maximum frequency, so confirm those before you commit a tight cadence. For the syntax itself, the cron expression guide has worked examples, and the cron scheduling page covers the model in more depth.
Reaching a protected endpoint
Most real tasks should not sit on an open URL. Public evidence supports Basic authentication with a username and password for protected endpoints, so the scheduler can call a route that rejects anonymous callers. [ostr.io/info/web-cron, accessed ] That covers carrying the credentials; the harder part is yours.
Before you schedule a protected route, review it for least privilege, secret rotation, and response clarity. A scheduled job should use a credential scoped to that job, not one borrowed from an admin account, and the secret should be rotatable without editing the task by hand. The Basic Auth page covers the failure modes worth planning for, including credentials that leak through a referrer header or a verbose log line.
What you can see after a run
A schedule is only as trustworthy as what it lets you inspect. Public evidence supports task information that includes logs and the latest response body, which is exactly what you need to tell four outcomes apart: an endpoint bug, an authentication failure, a server outage, and a clean run. [ostr.io/info/web-cron, accessed ] Each leaves a different fingerprint in the status code and the response. In practice they show up differently: a 401 or 403 points at the authentication check, a 5xx usually points at a bug inside the task, a request that never completes points at an unavailable server, and a 2xx with the body you expected is a clean run. Designing the endpoint so those cases stay distinct is what makes the logs worth reading.
This is why response design matters. A short, honest body with a correlation ID turns a vague report of failure into a traceable event. The execution control page covers logs, the latest response, retries, pause, and resume together, so you can see what is available after success or failure.
When a run fails: retry before alert
Failures are normal, and the useful question is what happens next. Public evidence supports one specific behavior: when the server is unavailable, Web CRON can retry before it raises an alert. [ostr.io/info/web-cron, accessed ] That is the verified statement, and this page keeps to it.
What the public documentation does not state, and what this page therefore does not invent, is the retry count, the interval, the backoff, any timeout rule, the alert channel, the recipient model, or a delivery guarantee. Plan your own status codes and escalation around the one fact that is confirmed, and treat the rest as questions for the product. The failure alerts page goes deeper on the verified retry-before-alert behavior and on keeping channel-specific claims out of your planning until you have checked them.
