conductor-oss/conductor · error · TerminateWorkflowException

Task timed out after %d seconds. Timeout configured as %d se

Error message

Task timed out after %d seconds. Timeout configured as %d seconds. Timeout policy configured to %s

What it means

timeoutTaskWithTimeoutPolicy sets the task to TIMED_OUT with the given reason and, when taskDef.timeoutPolicy is TIME_OUT_WF, throws a TerminateWorkflowException (status TIMED_OUT) that terminates the workflow. The reason string is built by callers (e.g. response-timeout, poll-timeout, total-timeout) and reports seconds elapsed, configured timeout, and policy.

Source

Thrown at core/src/main/java/com/netflix/conductor/core/execution/DeciderService.java:892

                        taskDef.getTimeoutPolicy().name());
        timeoutTaskWithTimeoutPolicy(reason, taskDef, task);
    }

    void timeoutTaskWithTimeoutPolicy(String reason, TaskDef taskDef, TaskModel task) {
        Monitors.recordTaskTimeout(task.getTaskDefName());

        switch (taskDef.getTimeoutPolicy()) {
            case ALERT_ONLY:
                LOGGER.info(reason);
                return;
            case RETRY:
                task.setStatus(TIMED_OUT);
                task.setReasonForIncompletion(reason);
                return;
            case TIME_OUT_WF:
                task.setStatus(TIMED_OUT);
                task.setReasonForIncompletion(reason);
                throw new TerminateWorkflowException(reason, WorkflowModel.Status.TIMED_OUT, task);
        }
    }

    @VisibleForTesting
    boolean isResponseTimedOut(TaskDef taskDefinition, TaskModel task) {
        if (taskDefinition == null) {
            LOGGER.warn(
                    "missing task type : {}, workflowId= {}",
                    task.getTaskDefName(),
                    task.getWorkflowInstanceId());
            return false;
        }

        if (task.getStatus().isTerminal() || isAyncCompleteSystemTask(task)) {
            return false;
        }

        // calculate pendingTime

View on GitHub (pinned to cf7c3e4a8a)

Solutions

Raise responseTimeoutSeconds / pollTimeout on the TaskDef to fit the real worker latency.
Change timeoutPolicy to RETRY (re-queue) or ALERT_ONLY (log only) if termination is too aggressive.
Diagnose why the worker is not updating the task (worker down, queue backlog, network).
Ensure the task implementation reports status before the configured timeout.

Defensive patterns

Strategy: validation

Validate before calling

// Warn if per-attempt timeout < typical worker latency.
if (td.getResponseTimeoutSeconds() > 0 && td.getResponseTimeoutSeconds() < p99WorkerSeconds(taskType)) {
    LOGGER.warn("responseTimeoutSeconds for {} likely too low", taskType);
}

Try / catch

try {
    deciderService.decide(workflow);
} catch (TerminateWorkflowException e) {
    if (e.getMessage().contains("Task timed out")) {
        // raise responseTimeoutSeconds or switch policy to RETRY/ALERT_ONLY
    }
}

Prevention

Set responseTimeoutSeconds/pollTimeout from measured worker p99 latency.
Choose RETRY or ALERT_ONLY instead of TIME_OUT_WF when termination is too harsh.
Ensure workers update task status before the timeout.

When it happens

Trigger: A per-attempt task timeout (responseTimeoutSeconds or pollTimeout) elapses on a task whose TaskDef.timeoutPolicy == TIME_OUT_WF.

Common situations: A worker not polling/updating within responseTimeoutSeconds; a hung external system; timeoutPolicy left at TIME_OUT_WF when ALERT_ONLY or RETRY was intended.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14). Data as JSON: /api/errors/0ccd5227102bb71c. Report an issue: GitHub.