Skip to main content
When a node fails—from a slow external API, a transient network error, or an unhandled exception—LangGraph gives you three composable mechanisms to respond:
  • Retries — automatically re-run failed attempts based on exception type and backoff settings
  • Timeouts — cap how long a single attempt may run
  • Error handling — run a recovery function after all retries are exhausted
Use set_node_defaults to configure these mechanisms once for all nodes instead of repeating them on every add_node call. These compose in a fixed order: when a node attempt raises any exception (including NodeTimeoutError from a timeout), the retry policy decides whether to retry. Only after retries are exhausted does the error handler run. For stopping a run cleanly at a superstep boundary and resuming later, see Graceful shutdown.
Per-node timeouts and node-level error handlers require langgraph>=1.2.

Retries

A retry policy automatically re-runs a failed node attempt based on exception type and backoff settings. Pass retry_policy= to add_node:

Default behavior

By default, retry_on uses default_retry_on, which retries on any exception except the following (and their subclasses):
  • ValueError
  • TypeError
  • ArithmeticError
  • ImportError
  • LookupError
  • NameError
  • SyntaxError
  • RuntimeError
  • ReferenceError
  • StopIteration
  • StopAsyncIteration
  • OSError
For exceptions from popular HTTP libraries such as requests and httpx, it only retries on 5xx status codes. NodeTimeoutError is retryable by default.

Parameters

Custom retry logic

Pass a callable or exception type to retry_on. Import default_retry_on to extend the default behavior:

Inspect retry state

Use runtime.execution_info inside a node to inspect the current attempt number. This is useful for switching to a fallback when the primary call keeps failing:
execution_info exposes the following fields: execution_info is available even without a retry policy—node_attempt defaults to 1.

Timeouts

Requires langgraph>=1.2.
The timeout= parameter on add_node caps how long a single node attempt may run. Pass a number (seconds), a timedelta, or a TimeoutPolicy for separate run and idle limits:
Node timeouts only apply to async nodes. Sync nodes with a timeout are rejected at compile time. To wrap blocking I/O, use asyncio.to_thread inside an async node.

Run timeout

run_timeout is a hard wall-clock cap on a single attempt. It is never refreshed, regardless of node activity:
When the limit is exceeded, LangGraph raises NodeTimeoutError, clears any writes from the failed attempt, and lets the retry policy decide whether to retry.

Idle timeout

idle_timeout is a progress-resetting cap. It fires only when the node stops making observable progress for the specified duration—unlike run_timeout, the clock resets whenever the node produces a progress signal:
You can set run_timeout and idle_timeout together. Whichever fires first cancels the attempt.

Progress signals

Under the default refresh_on="auto", the idle clock resets on any of the following:
  • State writes via CONFIG_KEY_SEND
  • Stream output (yielded async stream chunks)
  • Child-task scheduling
  • Runtime stream-writer calls
  • Any LangChain callback event from the node or its descendants (LLM tokens, tool calls, chain start/end, etc.)

Heartbeat mode

Set refresh_on="heartbeat" to narrow the refresh source to explicit runtime.heartbeat() calls only. This is useful when you want a strict idle definition that isn’t reset by chatty subordinates:

Manual heartbeats

For long-running async work that doesn’t naturally emit progress signals, call runtime.heartbeat() to manually reset the idle clock:
runtime.heartbeat() is a no-op outside an idle-timed attempt, so you can call it unconditionally.

NodeTimeoutError

When a timeout fires, LangGraph raises NodeTimeoutError with structured context about which limit was hit: NodeTimeoutError is retryable by default. Combining timeout= with retry_policy= works out of the box—the timeout clock resets on each new attempt, and writes from a timed-out attempt are cleared before the next retry:

Dynamic timeouts with Send

When using Send to dispatch nodes dynamically (for example, in map-reduce patterns), you can pass a timeout= directly on the Send to override the target node’s static timeout for that specific push:
If timeout= is omitted on the Send, the target node’s timeout (set at add_node time) applies. This lets you set a default timeout on the node and tighten it for individual calls.

Error handling

Requires langgraph>=1.2.
An error handler runs after a node fails and all retries are exhausted. It receives the current state and can update it or route to a different node using Command. This is useful for compensation flows (Saga patterns) where you want to recover gracefully rather than abort the entire graph. Pass error_handler= to add_node:
The handler fires only after retry_policy is exhausted, or immediately if no retry policy is configured. The retry policy and the error handler stay decoupled: configure when to retry and when to compensate independently.

NodeError

Error handlers receive failure context through a typed error: NodeError parameter, injected by type annotation (the same pattern as runtime: Runtime):
NodeError is a frozen dataclass with two fields: The error: NodeError parameter is opt-in. Handlers that don’t need failure context can use simpler signatures like (state) or (state, runtime).

Route with Command

Error handlers can return a Command to update state and route to a specific node, enabling Saga / compensation patterns:
charge_payment retries on ConnectionError up to 3 times. If retries are exhausted (or the error isn’t a ConnectionError), the handler compensates by updating state and routing to finalize instead of aborting the graph.

Resume-safe failures

Failure provenance is checkpointed. If the graph is interrupted or the process crashes after a node fails but before the handler completes, the handler sees the same NodeError context when the graph resumes from its checkpoint.

Behavior with interrupt()

interrupt() raised inside a node is not routed to the error handler. Interrupts use the GraphBubbleUp mechanism to pause graph execution for human-in-the-loop workflows, bypassing both retry policies and error handlers. The graph pauses as usual.

Subgraph failures

If a node wraps a subgraph and the subgraph raises an unhandled exception, that exception surfaces to the parent node. If the parent node has an error_handler, the handler fires with the subgraph’s exception in error.error.

Graph defaults

Requires langgraph>=1.2.
Instead of repeating the same retry_policy=, error_handler=, timeout=, or cache_policy= on every add_node call, use set_node_defaults() to configure graph-wide defaults in one place:
Both step_a and step_b now share the same retry policy, error handler, and timeout without any duplication.

Precedence

Per-node values passed directly to add_node() always override the defaults set by set_node_defaults(). Defaults are resolved at compile() time, so you can call set_node_defaults() before or after add_node() in any order:

Default error handler

The error_handler default is particularly valuable when you want a single catch-all recovery function for any node that fails without its own handler. The handler accepts the same (state, error: NodeError) signature described in Error handling:
The node is retried twice, then default_handler runs. The default handler also accepts RunnableConfig as an optional third argument if you need access to config values such as thread_id:

Applicability matrix

Not all defaults apply to all node types. Error-handler nodes (those registered via add_node(error_handler=...)) are excluded from certain defaults to prevent unsafe behavior:

Scope

Defaults set on a parent graph are not inherited by subgraphs. Each graph maintains its own defaults.

Functional API

The same timeout= and retry_policy= parameters are available on @task and @entrypoint in the functional API:
The behavior is identical to add_node: NodeTimeoutError is raised on timeout, buffered writes are cleared, and the retry policy decides whether to retry.

Graceful shutdown

Requires langgraph>=1.2.
Graceful shutdown lets you stop an in-flight graph run cooperatively—after the current superstep completes—and save a resumable checkpoint. This is useful for handling SIGTERM signals or any external supervisor that needs to reclaim resources without losing work. Create a RunControl and pass it as control= to invoke or stream. Call request_drain() from any thread to signal that the run should stop:

Semantics

Drain is cooperative and operates between supersteps, never preempting work that is already running:

Resume after drain

Resume a drained run with invoke(None, config) using the same thread_id:

Read drain state inside a node

Access drain state through the runtime parameter to adjust node behavior before the superstep boundary is reached:

SIGTERM hook pattern

The recommended pattern for handling process shutdown:
request_drain() does not cancel running asyncio tasks or kill threads. For a hard upper bound, pair drain with a graceful timeout and task cancellation.

Limitations

  • Python only: timeouts and error handlers are not available in the JavaScript/TypeScript SDK. Retry policies work in both Python and TypeScript.
  • Timeouts are async-only: sync nodes with a timeout are rejected at compile time.
  • One handler per node: each node can have at most one error_handler.
  • Handler failures bubble up: if the error handler itself raises, that exception propagates as if the node had no handler.
  • set_node_defaults is not inherited by subgraphs: each graph manages its own defaults independently.