Jobs
A job defines a unit of work that Outcron executes on a schedule or on demand. Every job has a type, a configuration, and execution settings that control timeout and retry behavior.
Job Types
HTTP
Makes an HTTP request to a URL. This is the most common job type.
| Field | Required | Default | Description |
|---|---|---|---|
url | Yes | — | The target URL |
method | No | GET | HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) |
body | No | — | Request body (for POST, PUT, PATCH) |
headers | No | — | Key-value map of HTTP headers |
success_status_policy | No | default | Success policy. default treats 200-299 as success; custom uses success_statuses |
success_statuses | No | — | Custom-only comma-separated success status codes or ranges, such as 200,201,202,204 or 200-204 |
retry_on_statuses | No | — | Explicit comma-separated HTTP status codes that trigger a retry, such as 429,502,503 |
An HTTP job succeeds when the response status code is 200-299 by default. Redirects, other non-2xx statuses, response body read errors, and network/policy failures are recorded as failures. Use success_status_policy=custom with success_statuses when a job needs a different explicit success set. Request bodies are capped at 1 MiB. Headers and bodies are encrypted at rest and redacted where execution snapshots or audit-style surfaces would otherwise expose them.
Health Check
Monitors the availability of a URL by checking its response status code.
| Field | Required | Default | Description |
|---|---|---|---|
url | Yes | — | The URL to check |
expected_status | No | 200 | Expected HTTP status code |
A health check succeeds when the response matches the expected status code.
Container
Runs a command inside a container image.
| Field | Required | Default | Description |
|---|---|---|---|
image | Yes | — | Container image (e.g., alpine:latest) |
command | No | — | Command to run (string or array). Strings are wrapped in /bin/sh -c. |
env | No | — | Environment variables as a key-value map; keys must match ^[A-Za-z_][A-Za-z0-9_]*$ |
registry_credential_id | No | — | ID of a registry credential for private image pulls |
A container job succeeds when the process exits with code 0.
Container jobs require a Docker or Podman runtime available to the executor host. Container-backed job types use hardened defaults: all Linux capabilities dropped, no-new-privileges, resource limits, read-only rootfs with writable /tmp, non-root execution by default, and network isolation with private-range egress blocks.
Script
Runs an inline script in a language-specific container.
| Field | Required | Default | Description |
|---|---|---|---|
language | Yes | — | Script language: built-in python, nodejs, bash, go, or ruby, plus any platform-configured additions |
script | Yes | — | The script source code to execute |
requirements | No | — | Package dependencies (pip packages for Python, npm packages for Node.js) |
env | No | — | Environment variables as a key-value map; keys must match ^[A-Za-z_][A-Za-z0-9_]*$ and cannot use reserved runtime names |
secret_env | No | — | Encrypted environment variables (redacted in execution snapshots); keys use the same env-name and reserved-name rules |
Each language uses a dedicated container image with the runtime pre-installed. Platform admins can add custom script languages only when they also configure the image for that language. A script job succeeds when the script exits with code 0.
Inline script source is capped at 256 KiB. Requirements should be package specifiers, not installer flags; pin versions for repeatable runs. Runtime entrypoints reject invalid env names and reserved names such as OUTCRON_CONFIG; Go scripts also reserve GOCACHE and GOPATH.
Database
Executes a query or maintenance action against a database.
| Field | Required | Default | Description |
|---|---|---|---|
db_type | Yes | — | Database type: postgres, mysql, mongodb, or redis |
host | No | — | Database hostname (required unless connection_string is set) |
port | No | per db_type | Database port |
database | No | — | Database or schema name |
username | No | — | Database username |
password | No | — | Database password (encrypted) |
connection_string | No | — | Full connection URI (encrypted, alternative to individual fields) |
script | No | — | SQL or query script to execute (one of script or action_template is required) |
action_template | No | — | Predefined maintenance action (e.g., backup, vacuum, reindex for Postgres; backup, optimize for MySQL) |
max_rows | No | 1000 | Maximum number of rows returned in results |
tls_mode | No | disable | TLS mode: disable, require, verify-ca, or verify-full |
tls_ca_cert | No | — | PEM CA certificate for verify-ca or verify-full |
A database job succeeds when the query or action completes without error.
Use either individual connection fields with password or a connection_string. Use either script or an action_template. max_rows defaults to 1000 and is capped by the deployment's platform setting.
Cloud CLI
Runs a cloud provider CLI command in a container.
| Field | Required | Default | Description |
|---|---|---|---|
tool | Yes | — | CLI tool: built-in aws, gcloud, az, kubectl, or terraform, plus any platform-configured additions |
command | No | — | Raw CLI command to execute (one of command or template is required) |
template | No | — | Templated command with parameter substitution |
parameters | No | — | Key-value map of parameters (injected as environment variables); keys must match ^[A-Za-z_][A-Za-z0-9_]*$ and cannot shadow provider credential names |
credentials | No | — | Cloud provider credentials (encrypted, string or JSON object) |
A cloud CLI job succeeds when the command exits with code 0.
Provide exactly one of command or template; command/template strings are capped at 16 KiB. Parameters are injected as environment variables and cannot shadow provider credential env names.
Cloud Function
Invokes a serverless function on a cloud provider.
| Field | Required | Default | Description |
|---|---|---|---|
provider | Yes | — | Cloud provider: built-in aws, gcp, or azure, plus any platform-configured additions |
function_id | Yes | — | Function identifier (ARN, name, or resource ID) |
payload | No | — | JSON payload to pass to the function |
invocation_type | No | sync | Invocation mode: sync (wait for result) or async (fire-and-forget) |
region | No | — | Cloud region |
credentials | No | — | Cloud provider credentials (encrypted, string or JSON object) |
A cloud function job succeeds when the invocation completes without error.
Payloads must be valid JSON strings. sync waits for the provider invocation result; async submits the invocation and returns after the provider accepts it.
Git Workflow
Clones a git repository and executes a script from within it.
| Field | Required | Default | Description |
|---|---|---|---|
repo_url | Yes | — | Git repository URL |
script_path | Yes | — | Relative path to the script within the repo (no .. allowed) |
branch | No | main | Branch to check out |
subdir | No | — | Subdirectory to change to before running the script |
args | No | — | Arguments to pass to the script (string array) |
auth | No | — | Git authentication (provide token or ssh_key, not both) |
env | No | — | Environment variables as a key-value map; keys must match ^[A-Za-z_][A-Za-z0-9_]*$ and cannot use git workflow control names |
secret_env | No | — | Encrypted environment variables (redacted in execution snapshots); keys use the same env-name and reserved-name rules |
clone_timeout_sec | No | 60 | Timeout for the git clone step in seconds (1–3600). |
A git workflow job succeeds when the script exits with code 0.
Use either token auth or SSH-key auth, not both. SSH flows can pin known hosts. Paths must be relative and stay inside the clone; args are bounded, and clone_timeout_sec only bounds the clone step.
IaC Drift
Detects infrastructure drift by running a plan or preview against a live environment.
| Field | Required | Default | Description |
|---|---|---|---|
iac_type | Yes | — | IaC tool: built-in terraform or pulumi, plus any platform-configured additions |
repo_url | Yes | — | Git repository URL containing the IaC configuration |
branch | No | main | Branch to check out |
working_dir | No | — | Working directory within the repo (relative path) |
command | No | — | Custom plan/preview command override |
auth | No | — | Git authentication (provide token or ssh_key, not both) |
credentials | No | — | Cloud provider credentials for drift detection (encrypted) |
An IaC drift job succeeds when the plan/preview command completes. The output includes structured drift detection status. Custom command first verbs are restricted by platform policy; mutating verbs remain policy-sensitive when allowed.
ETL
Extracts data from a source, optionally transforms it, and loads it into a destination.
| Field | Required | Default | Description |
|---|---|---|---|
source_type | Yes | — | Source type: postgres, mysql, api, or file |
source_config | Yes | — | Source connection details (see below) |
dest_type | Yes | — | Destination type: postgres, mysql, api, or file |
dest_config | Yes | — | Destination connection details (see below) |
transform_script | No | — | Transformation logic applied between extract and load |
mapping_rules | No | — | Field mapping rules as a JSON object |
Source/destination config for database types (postgres, mysql):
| Field | Description |
|---|---|
host | Database hostname |
port | Database port |
database | Database name |
username | Username |
password | Password (encrypted) |
tls_mode | Optional TLS mode |
tls_ca_cert | Optional CA certificate (encrypted) |
query | SQL query (source only) |
table | Target table (destination only) |
Source/destination config for API type:
| Field | Description |
|---|---|
url | API endpoint URL |
api_key | API key (encrypted) |
Destination mode (in dest_config):
| Value | Description |
|---|---|
append | Insert new rows (default) |
replace | Replace all existing data |
upsert | Insert or update based on key |
An ETL job succeeds when the full extract-transform-load pipeline completes without error.
mapping_rules must be a string-to-string object. Source credentials are only available to extract, destination credentials only to load, and transform_script runs in a separate transform stage without source or destination credentials.
Container Security
Most jobs require the executor container capability and run in a container behind the scenes. The registered exceptions are http and healthcheck; all other job types are container-backed: container, script, database, cloud-cli, cloud-function, git-workflow, iac-drift, and etl. The containers run with security hardening. Keep these details in mind as you plan your use of Outcron.
- Read-only filesystem with a writable
/tmp(256 MB tmpfs) - All Linux capabilities dropped and
no-new-privilegesenforced - Non-root user (
65534:65534) by default - Resource limits: 512 MB memory, 1 CPU, 256 PIDs
- Network isolation: containers run in an isolated network with firewall rules blocking private IP ranges
Execution Settings
These settings apply to all job types:
| Field | Default | Description |
|---|---|---|
timeout_sec | 30 | Maximum execution time in seconds. Must be between 1 and platform job_execution_timeout_max (default 3600, hard cap 86400). The execution is marked as timeout if exceeded. |
retry_count | 0 | Number of times to retry on failure. Must be no greater than platform job_retry_count_max (default 10). |
retry_delay_sec | 5 | Seconds to wait between retry attempts. With retries enabled, explicit nonzero values must be at least platform job_retry_delay_min_sec (default 1). |
no_overlap | false | Prevents a new run while another execution for the same job is pending, claimed, or running. |
timeout_sec must be between 1 and platform job_execution_timeout_max. retry_count and retry_delay_sec must be non-negative integers. The combined retry workload budget (timeout_sec * (retry_count + 1)) + (retry_delay_sec * retry_count) must be no greater than platform job_retry_total_budget_max_sec (default 7200).
Retry Behavior
When a job fails and has retry_count > 0, Outcron retries automatically inside the same running execution row:
- The failed attempt records its result, but the execution stays
runningwhile another retry is eligible. - After
retry_delay_sec, the next attempt starts in that same execution. - Each attempt increments the attempt counter in place.
- The execution receives a terminal status only after success, a non-retriable result, cancellation or interruption, timeout, or the final failed attempt.
For HTTP jobs, you can use retry_on_statuses to retry on configured status codes such as 429 or 5xx provider failures. The CLI accepts aws and gcp shortcuts and expands them into explicit status-code lists before sending the API request. This is separate from success_status_policy, which decides whether the HTTP response is successful before retry eligibility is evaluated.
No-Overlap Runs
Enable no_overlap when a job must not run concurrently with itself. While an execution for that job is pending, claimed, or running, scheduled runs are skipped and manual triggers return a conflict response. This is useful for migrations, ETL loads, and other workflows that are not safe to overlap.
Job Lifecycle
- Active — the job runs on its attached schedules and can be triggered manually.
- Inactive — the job still exists but won't be executed. Toggle via the
is_activeflag.
Deleting a job is permanent. Existing execution history for a deleted job is retained.