How Cronevra works

Cronevra calls a URL you own, on a schedule you set, and records what happened. It does not run your code — every job is one outbound HTTP request and the response it gets back.

The request

A job is a method, a URL, and optionally headers, a bearer token and a JSON body. Methods: GET, POST, PUT, PATCH. A body is sent on POST, PUT and PATCH, and must be valid JSON.

DELETE is not offered. A scheduled DELETE against a mistyped URL runs unattended and cannot be undone, so it needs a confirmation step at save time that does not exist yet.

Bearer tokens and bodies are encrypted at rest and are never shown back to you after saving — if you lose one, replace it. Only https:// and http:// URLs on ordinary web ports are accepted, and credentials in the URL itself are refused.

Schedules

A schedule is a 5-field cron expression — minute, hour, day of month, month, day of week — evaluated in an IANA time zone you choose per job. The visual builder compiles down to the same expression, so there is one stored representation and daylight-saving is handled by the zone rather than by you.

How often a job may run depends on your plan; the fastest allowed interval is in the table below. A schedule quicker than your plan's floor is refused when you save it, not silently slowed down.

Retries

A failed attempt is retried up to your plan's limit, and immediately— there is no backoff between attempts. Every attempt is recorded as its own execution, including the ones that were retried, because “it succeeded on the third try” is exactly the diagnostic that gets hidden when only the final outcome is stored.

Not everything is retried. A refused destination or an oversized response will fail again identically, so retrying only spends your allowance — the table at the end says which codes are retried and which are not.

What your plan allows

One Evra subscription covers Cronevra at the matching level alongside every other product — see pricing.

Limits that no plan raises

These are safety limits rather than commercial ones. They bound what a single outbound request can cost in time, memory and bandwidth, so they apply on every plan including the top one.

• 30s absolute request timeout, and 2 retries, whatever a plan says.
• 1 MB of response downloaded before we stop — only a short preview is stored, so a larger body is never needed.
• 3 redirect hops followed, each one re-validated against the destination rules below.
• 64 KB request body, and 2,048 characters of URL.

Where requests can go

Cronevra's whole function is to fetch a URL a stranger typed in, from inside our infrastructure, so the destination check is deliberately paranoid and runs in two layers. The URL is checked when you save the job — scheme, port, credentials, hostname — and every address DNS returns is checked again at connect time, for the original request and for every redirect hop.

Private, loopback, link-local and cloud-metadata addresses are refused. We connect to the exact address that was approved rather than re-resolving the hostname, so DNS cannot change under us between the check and the connection. A URL that fails up front is blocked_ssrf; a redirect into private space is blocked_redirect.

Response previews

Only a short preview of each response is stored, sized by your plan, and it is redacted before it is written — not before it is displayed. Responses routinely echo the request: error pages print the Authorization header they received, OAuth endpoints hand back fresh tokens. Redacting at display time would leave the secret in the database for the next feature that reads the column.

When a run fails

Every failed execution carries one of these codes. Branch on the code, not the message.