Cron Schedules

A cron schedule is a recurring HTTP request that Recuro fires on a standard cron expression. Each execution is logged with the full HTTP request and response, and you can configure alerts to notify you when failures exceed a threshold.

How cron schedules work

You create a cron with a URL, HTTP method, and cron expression
Recuro evaluates the cron expression and calculates the next run time
At the scheduled time, Recuro sends the HTTP request to your endpoint
The execution result (status code, response body, duration) is recorded
The next run time is calculated and the cycle repeats

Crons are processed every minute. When a cron’s next_run_at is in the past, Recuro dispatches the HTTP call and immediately calculates the next occurrence — preventing duplicate executions even under load.

Cron expression syntax

Recuro uses standard 5-field cron expressions:

┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-7, where 0 and 7 are Sunday)
│ │ │ │ │
* * * * *

Common patterns

Expression	Description
`* * * * *`	Every minute
`/5 * * *`	Every 5 minutes
`0 * * * *`	Every hour (at minute 0)
`0 0 * * *`	Daily at midnight
`0 9 * * 1-5`	Weekdays at 9 AM
`0 0 * * 1`	Every Monday at midnight
`0 0 1 * *`	First day of every month at midnight
`30 2 * * *`	Daily at 2:30 AM

Special characters

Character	Meaning	Example
`*`	Any value	`* * * * *` (every minute)
`,`	List of values	`0,30 * * * *` (at minutes 0 and 30)
`-`	Range	`0 9-17 * * *` (every hour from 9 AM to 5 PM)
`/`	Step	`/15 * * *` (every 15 minutes)

Execution lifecycle

Each cron execution goes through these states:

Status	Description
`pending`	Execution created, waiting to start
`processing`	HTTP request is in flight
`completed`	Request finished successfully (2xx and all assertions passed)
`failed`	Request failed (non-2xx, timeout, connection error, or assertion failure)

What gets recorded

Every execution captures:

Request: HTTP method, URL, headers, body
Response: status code, body, headers
Timing: started at, completed at, duration in milliseconds
Failure reason (if failed): timeout, connection_error, http_client_error, http_server_error, dns_error, ssl_error, invalid_url, assertion_failed, limit_exceeded, or unknown

Success assertions

Assertions let you define conditions that the HTTP response must satisfy for an execution to count as successful. If any assertion fails, the execution is marked as failed with reason assertion_failed.

Type	Description	Example value
`status_code_equals`	Response status code must equal this value	`"200"`
`status_code_in`	Response status code must be one of these comma-separated values	`"200,201,204"`
`body_contains`	Response body must contain this string	`"ok"`
`body_not_contains`	Response body must not contain this string	`"error"`
`json_path_equals`	A JSON path in the response must equal the given value (format: `path=value`)	`"data.status=active"`
`response_time_under_ms`	Response time must be under this many milliseconds	`"5000"`

You can add up to 10 assertions per cron. All assertions must pass for the execution to succeed.

Timeout

Each cron has a configurable timeout (1-300 seconds, default: 30 seconds). If your endpoint does not respond within the timeout, the execution is marked as failed with reason timeout.

Alert threshold

Set alert_threshold to 1, 2, or 3 to control how many consecutive failures trigger an alert:

After the first failure, a warning alert is created
After alert_threshold consecutive failures, a failure alert is sent to your notification channel
When the cron succeeds again after being in a failure state, a recovery alert is sent

The consecutive failure counter resets to 0 on any successful execution.

Pause and resume

Toggle a cron’s active state from the dashboard or by passing is_active: false when creating via the API. Paused crons do not fire, but their configuration is preserved. Resume them at any time and the next run is calculated from that point forward.

Manual execution

You can trigger a cron execution manually from the dashboard by clicking Run Now on any cron. This fires the HTTP request immediately regardless of the cron schedule and records the execution in the history.

Completion callbacks

If you set a callback_url on a cron, Recuro sends a POST request to that URL after each execution completes (success or failure):

{
  "type": "cron_execution",
  "cron_id": "uuid",
  "execution_id": "uuid",
  "status": "success",
  "response_status": 200,
  "duration_ms": 142,
  "error_message": null,
  "completed_at": "2026-04-10T12:05:01Z"
}

Callbacks are fire-and-forget with a 10-second timeout. If your team has a signing secret configured, the callback is signed with the same webhook signing mechanism.

Crons vs. queues

	Crons	Queues
Scheduling	Recurring (cron expression)	One-off (immediate or delayed)
Retries	No retries (each execution is independent)	Configurable retries with backoff
Dead-letter queue	Not applicable	Failed jobs land in DLQ after retries exhausted
Use case	Health checks, periodic syncs, scheduled reports	Webhook delivery, delayed tasks, background processing

Next steps

Create a Cron Job (API) — Full API reference
Queues — Learn about queue-based job scheduling
Alerts — Understand the alerting system
Cron Expression Patterns — Common patterns and pitfalls