HTTP jobs

Schedule HTTP requests with retries, timeouts, custom headers, and full request/response logging.

An HTTP job is an endpoint SteadyCron calls on a schedule. You focus on the handler; SteadyCron handles scheduling, retries, timeouts, and the audit trail.

Request configuration

Each HTTP job sends a request you fully control:

  • Method — GET, POST, PUT, PATCH, or DELETE.
  • URL — any HTTPS endpoint. (Only http/https schemes are allowed, and requests to internal/private addresses are blocked for safety.)
  • Headers — set custom headers, e.g. an Authorization bearer token.
  • Body — send a JSON or text payload with the request.

Retries and timeouts

Transient failures shouldn’t become permanent outages:

  • Timeout — abort a request that runs too long (up to 30 s on Free, 5 min on paid plans).
  • Retries — retry failed attempts with exponential backoff (up to 1 on Free, up to 5 on paid plans). Choose whether to retry on timeout and on specific status codes.
  • Skip if still running — don’t start a new run while the previous one is still in flight.

Misfire policy

If SteadyCron couldn’t fire a job at the scheduled minute (for example, right after a maintenance window), the misfire policy decides what happens:

  • Do nothing — skip the missed fire (good for digest-style jobs).
  • Fire once now — run immediately to catch up (good for backups).

Controls

Every job can be run now, paused, and resumed from the dashboard or the API. Pausing stops scheduling without deleting the job or its history.

Execution log

Every invocation is recorded with its timestamp, duration, HTTP status code, and a truncated copy of the response headers and body. Retries appear as separate attempts. Use the log to answer “did the 3am job run, and what did it return?”

Log retention depends on your plan — see Plans & limits.

Next steps