# Web CRON FAQ

Frequently asked questions about hosted Web CRON, scheduled HTTP tasks, and Web CRON by ostr.io. Product-specific statements are refreshed against official ostr.io sources.

## What is Web CRON?

Web CRON is a hosted way to run recurring work. Instead of a cron daemon living inside a server you maintain, a hosted scheduler calls a remote HTTP endpoint on a schedule you define. For Web CRON by ostr.io, public evidence supports triggering server tasks over HTTP using rules similar to classic Linux CRON. Your application still owns what the endpoint actually does.

## How is Web CRON different from server CRON?

Server CRON runs inside the operating system of a machine you maintain, so the schedule and the work sit together. Hosted Web CRON moves the schedule outside your application server and reaches your code through an HTTP call instead. The split is the point: the scheduler owns timing and invocation, while your endpoint still owns security, idempotency, and response output.

## Can Web CRON trigger remote HTTP tasks?

Yes. Public evidence supports Web CRON triggering server tasks over HTTP. The public documentation does not spell out protocol wording beyond that, so this page does not assert HTTPS as a separate product claim. Treat transport security as something to confirm against the official source and to enforce on your own endpoint.

## Does Web CRON use Linux-style CRON rules?

Yes — public evidence supports scheduling rules similar to classic Linux CRON, so a five-field expression you already know will look familiar. What is not confirmed in public documentation is the exact parser behavior, the default timezone, the smallest allowed interval, and any maximum frequency, so this page leaves those open.

## How can scheduled endpoints be protected?

Public evidence supports Basic authentication with a username and password for protected endpoints, which lets the scheduler reach a route that is not open to the public. Other mechanisms, such as bearer tokens, request signatures, IP allowlists, mTLS, or OAuth, are not confirmed for Web CRON in public documentation, so this page does not claim them. Pair Basic Auth with HTTPS on your side, and keep those credentials out of logs and referrer headers.

## What happens when a scheduled task fails?

When the server is unavailable, Web CRON can retry before it sends an alert — that is the one behavior public evidence confirms. The retry count, interval, backoff, timeout rules, alert channel, and any delivery guarantee are not confirmed in public documentation, so this page does not invent them. Plan your own status codes and escalation around that single verified point.

## Can I review logs or the latest response body?

Yes. Public evidence supports task information that includes logs and the latest response body, which is what turns an alert into a diagnosis. Design responses to help triage: a short body, a correlation ID, and no secrets.

## Can tasks be paused and resumed?

Yes. Public evidence supports pausing and resuming tasks. That is useful for maintenance windows, incident response, and a readiness check before you let a schedule run again.

## Are email and SMS alerts supported?

Specific email and SMS alert claims require product-owner validation before publication, so this page does not state how notifications are metered, how many recipients or phone numbers are allowed, or how they are billed. Until that validation is recorded, those details are left to the official source.

## How should I estimate cost?

Use the official pricing page for current rates and the estimator. This site does not mirror a tariff table. Where a worked example appears, it carries its calculation date, the assumptions behind it, the figure shown, and a note to refresh before relying on it.

## How should I compare alternatives?

Compare on the things that decide fit: endpoint support, the schedule model, authentication, execution visibility, failure handling, pause and resume, and the pricing model. Hold every option to the same criteria, and treat anything a source does not document as not confirmed rather than assumed.

## Where should I start?

If your endpoint exists and you have answered the schedule, authentication, failure, and cost questions above, getting started is the next step. It prepares the endpoint and hands off to the official product. From there, continue to Web CRON by ostr.io for current product information.

---

Official product: https://ostr.io/info/web-cron
Full FAQ: https://web-cron.info/faq/