Heartbeat
HEARTBEAT workflows perform lightweight health checks. They do not start general-purpose workload containers and never generate retained execution logs. log_retention is persisted as disabled.
Use heartbeat workflows for endpoint availability and infrastructure checks where a full container command is unnecessary.
Heartbeat targets must be publicly reachable endpoints. Requests that resolve to loopback, private (RFC 1918), CGNAT (100.64.0.0/10), link-local, multicast, IANA special-use (TEST-NET, documentation, benchmarking, reserved 0.0.0.0/8/192.0.0.0/24 except 192.0.0.9/192.0.0.10 PCP/TURN anycast, 240.0.0.0/4 etc.), or IPv6 outside strict global unicast 2000::/3 / special-use within it (2001::/32, 2001:10::/28, 2001:db8::/32, 2002::/16, 5f00::/8, default-deny 2001::/23 with globally-reachable exceptions 2001:3::/32, 2001:20::/28 etc.) are rejected at execution time and fail the job permanently with EXECUTION_FAILED. Well-known NAT64 64:ff9b::/96 is decoded to its embedded IPv4 and re-checked (64:ff9b::8.8.8.8 allowed, 64:ff9b::10.0.0.1 blocked), while local-use 64:ff9b:1::/48 remains blocked. The check is applied per connection attempt, so redirects and DNS rebinding cannot route a probe to an internal address. Deployments whose IPv6 egress traverses an RFC 6052 network-specific Pref64 translator declare its prefix through EXECUTION_WORKER_HEARTBEAT_NAT64_PREFIXES (comma-separated CIDRs of the RFC 6052 embedding lengths /32, /40, /48, /56, /64, or /96); addresses under a declared prefix are decoded to their embedded IPv4 form and re-checked by the same policy, including the reserved zero u octet at bits 64–71. Outbound heartbeats also honor standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment selection on every redirect hop. Proxied requests use CONNECT to a locally resolved and validated destination IP, while preserving the original HTTP Host and TLS SNI/certificate identity inside the tunnel; this prevents the proxy from resolving the user hostname through rebinding or split-horizon DNS. The configured proxy is operator trust and must permit CONNECT to the heartbeat destination ports.
Container
CONTAINER workflows describe a Docker image and command in the payload. The workflow worker resolves execution metadata, jobs-service assigns a fresh runtime node during claim, and the execution worker runs the workload through the runtime endpoint registered by runtime-agent.
Container workflows can retain stdout and stderr, stream output while running, and participate in text search and raw downloads after completion.
Every workload container runs isolated: it is attached to a dedicated chronoverse-workloads Docker network (never the default bridge) with inter-container communication disabled, so tenant workloads cannot reach each other even by IP. All Linux capabilities are dropped, privilege escalation is disabled (no-new-privileges), the root filesystem is read-only with a writable nosuid tmpfs at /tmp, and IPC is private. Internet egress remains available for legitimate jobs; host-published ports stay reachable from workloads via the network gateway and remain protected by the platform's own mTLS and authentication layers. Set EXECUTION_WORKER_WORKLOAD_NETWORK to pin workloads to a different network name — the runtime creates or revalidates it immediately before each workload and refuses to run if isolation cannot be guaranteed. Custom names must match [A-Za-z0-9][A-Za-z0-9_.-]* so they are portable across direct Docker and the Kubernetes socket proxy.
Shared controls
Both kinds support interval scheduling, manual runs, failure thresholds, termination, notifications, and analytics. Their execution and logging behavior differs, but they share replay-safe scheduling and lifecycle state.
Choosing a kind
Prefer heartbeat when the result is a health signal. Prefer container when the workload needs an image, command, environment, or output capture.