Cron vs Temporal for Microservice Scheduling

Use Cron for process-local recurring triggers

A Cron connector evaluates a portable five-field schedule and invokes a generated endpoint function. The callback can emit values into the service graph. This is useful when the task belongs to the running service and durable orchestration is not required.

Do not treat a local timer as a durable execution history. Decide explicitly what missed occurrences and duplicate side effects mean for your application. See Cron endpoints.

Use Temporal when execution must survive workers

Configure a Temporal connection, namespace and task queue. A Workflow runs in a deterministic environment; side effects belong in Activities. Temporal Schedules provide server-managed starts. Durable timers and execution state are different from an in-process delay.

Service Architect supports Temporal targets in Go, Python and TypeScript. The visual model configures contracts and runtime wiring; application Workflow and Activity code still has to satisfy Temporal requirements.

Configure retries and concurrency at the right boundary

Activity timeout, heartbeat and attempt settings apply to retryable work. Heartbeat recovery needs implementation heartbeats. A retry can repeat a side effect, so choose an idempotency strategy for the external operation.

Worker concurrency fields limit processed Activities or Workflow Tasks; they do not mean the same thing as the count of open Workflow executions. Consult the endpoint reference before sharing a task queue between endpoints.

Verify the restart and shutdown behavior

Run a controlled worker restart in a development environment and check what resumes. For shutdown, allow workers to drain within the service timeout. Test the application outcome as well as the fact that a worker reconnected.

Next steps

Recurring local callback → Cron
Replay-safe durable orchestration → Temporal Workflow
Retryable external work → Temporal Activity
Durable recurring start → Temporal Schedule

Related documentation