Skip to main content

​
Execution Model

This page explains what happens each time one of your schedules fires: how the outcome is decided, when Cronhost retries, and how executions count toward your plan.

​
Success and failure

By default, a job is a success when the response status is below 400 (any 2xx or 3xx). Any status of 400 or above is a failure, and so are network errors and timeouts. You can override this per schedule with expectedStatusCodes. It is a comma-separated list of 3-digit status codes and ranges. When set, only those codes count as success.
  • Omit the field or leave it blank to use the default rule (< 400).
  • Whitespace is ignored, so 200-299, 410 and 200-299,410 behave the same.
A common use case: an endpoint that returns 202 Accepted and later 409 Conflict on duplicate work, where you consider both healthy. Set expectedStatusCodes to 200-299,409.
fetch follows redirects, so a final 3xx response is uncommon in practice. Most schedules only need to think about 2xx versus 4xx/5xx.

​
Retries

When a job fails, Cronhost retries only when the failure looks transient:
  • 5xx server responses
  • 408 Request Timeout
  • 429 Too Many Requests
  • Connection or network errors
  • Request timeouts
Deterministic 4xx responses (such as 400, 401, 403, 404) are not retried, because repeating the same request would just fail again. Retries use exponential backoff. Each retry is recorded as its own job row with an incremented attemptNumber, sharing the original scheduled run time.

​
maxRetries

maxRetries is the total number of attempts including the first, not the number of extra tries. It is clamped to the range 1 to 10: a value of 0 is treated as 1, and values above 10 are capped. Out-of-range values are never rejected, so existing integrations keep working.

​
timeoutSeconds

timeoutSeconds is the per-request timeout, clamped to the range 1 to 300.

​
How executions count toward your plan

Your plan includes a monthly execution allowance (see Plans & Limits). An execution is a scheduled run or a manual trigger, counted once per scheduled run time. Retries are free. They are the platform’s reliability mechanism and do not consume your quota, so a flaky endpoint that needs several attempts still costs a single execution.

​
Notifications

Each schedule has a notification preference (notifyOn) that decides which outcomes alert you: none, failure, success, or both. Alerts are delivered to verified notification channels (email, Slack, Discord, or Telegram). See Notifications for how to set this up with the SDK, or the API reference for the raw endpoints.