On this page

Destination Types

Every cron worker has exactly one destination. Six types are available, covering the most common ways to fan out scheduled work in a service-oriented project.

Destination	Use it for
HTTP	Calling an endpoint on one of your services
NATS	Publishing to a NATS subject for other services to consume
Redis	Publishing to a Redis Pub/Sub channel
Valkey	Publishing to a Valkey Pub/Sub channel (Redis-compatible)
RabbitMQ	Publishing to an exchange with a routing key
Postgres	Sending a `NOTIFY` to a Postgres `LISTEN/NOTIFY` channel

The destination type is chosen at creation time and cannot be changed later. The destination’s configuration (path, subject, channel, etc.) is editable any time from the worker detail page.

HTTP

Calls a path on a service in your project. The cron worker resolves the service’s internal endpoint at runtime — you don’t need to copy URLs.

Field	What it is
Service	Pick from your project’s services. The worker uses the service’s primary endpoint.
Path	The path under the endpoint, starting with `/`. Maximum 2048 characters. Whitespace and control bytes are rejected.
Headers	Optional custom HTTP headers as `Name: value` pairs.

The worker always sends POST with the JSON payload as the body and Content-Type: application/json. The worker also sets Traceparent and Tracestate headers so the request joins the same trace as the cron fire.

Reserved headers

You cannot override these headers — they are managed by the platform:

Host, Authorization, Cookie, Connection, Upgrade, Transfer-Encoding, Content-Length, Traceparent, Tracestate

Header names must follow RFC 7230 (ASCII tokens). Invalid names are rejected at validation time.

SSRF protection

HTTP destinations are restricted to your own services. The orchestrator blocks any resolved host that lands on:

Loopback (127.0.0.0/8, ::1)
RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Link-local (169.254.0.0/16, fe80::/10)
Carrier-grade NAT (RFC 6598, 100.64.0.0/10)
Unique-local IPv6 (fc00::/7)
IPv4-mapped IPv6
The unspecified address (0.0.0.0/8, ::)

Blocked attempts are recorded as runs with failure_reason: ssrf_blocked so you can see them in the history.

NATS

Publishes the JSON payload to a NATS subject. The cron worker reads connection details and credentials from the catalog NATS service automatically.

Field	What it is
Service	A NATS catalog service in your project.
Subject	The subject to publish on (e.g., `jobs.daily-digest`).

Publishing is fire-and-forget at the NATS protocol level. A run is marked success once the broker has accepted the message.

Redis and Valkey

Publishes the JSON payload to a Redis or Valkey Pub/Sub channel. Valkey is the Redis-compatible drop-in available in the catalog.

Field	What it is
Service	A Redis or Valkey catalog service in your project.
Channel	The Pub/Sub channel name (e.g., `cache:warmup`).

The worker uses PUBLISH <channel> <payload> and considers the run success once the server confirms delivery to the channel. Note that Redis Pub/Sub does not buffer — if no subscribers are listening, the message is dropped (this is how Redis Pub/Sub works, not a Guara Cloud limitation).

RabbitMQ

Publishes the JSON payload to a RabbitMQ exchange with a routing key.

Field	What it is
Service	A RabbitMQ catalog service in your project.
Exchange	The exchange to publish to.
Routing key	The routing key (e.g., `reports.daily`).
Require routable	When enabled, fail the run if the broker reports the message as unroutable (no queue bound to the exchange/routing key). When disabled (default), publishing is fire-and-forget.

Use Require routable when the schedule should fail loudly if no consumer is listening — for example, if a misconfigured deployment removed the binding for a critical job.

Postgres NOTIFY

Sends a Postgres NOTIFY on a channel. Useful for fan-out to in-database listeners or for triggering pg_notify-driven workflows.

Field	What it is
Service	A Postgres catalog service in your project.
Channel	The channel name to notify on (e.g., `jobs_pending`).

The worker wraps the JSON payload inside a small _meta envelope with the run ID and a W3C traceparent, then runs NOTIFY <channel>, '<envelope>'. Listeners receive the envelope as the NOTIFY payload string.

NOTIFY jobs_pending, '{"_meta":{"run_id":"...","traceparent":"00-..."},"payload":{...}}'

Failure reason taxonomy

Every failed run carries a structured failure_reason that the run history surfaces with a friendly label. The full set:

Code	When it fires
`timeout`	The destination did not respond within the configured timeout.
`dns`	Hostname resolution failed.
`connection`	TCP/socket connection failed (refused, reset, unreachable).
`tls`	TLS handshake failed (bad cert, unsupported protocol).
`http_4xx`	HTTP destination returned a `4xx` other than `408` / `429`. Permanent — not retried.
`http_5xx`	HTTP destination returned a `5xx`. Retried up to the configured limit.
`ssrf_blocked`	HTTP destination resolves to a blocked address (private, loopback, etc.). Permanent.
`credential`	Catalog service credentials could not be resolved or were rejected by the destination.
`protocol`	Destination protocol error (NATS publish error, RabbitMQ unroutable when required, etc.).
`unknown`	Anything else — check the `error` field for details.