Transaction Timeout Configuration

Transaction timeout configuration lets workspace admins control how long Fireblocks waits for a transaction to be broadcast to the blockchain before marking it as failed. By default, all workspaces use a 2-hour timeout. You can customize this globally, per signing method, or per individual transaction, depending on your operational needs.

How it works

Fireblocks monitors every transaction from creation through all pre-broadcast statuses:

• SUBMITTED
• PENDING_AML_SCREENING
• PENDING_ENRICHMENT
• PENDING_AUTHORIZATION
• QUEUED
• PENDING_SIGNATURE

If the transaction is not broadcast to the blockchain within the configured timeout window, Fireblocks transitions it to status FAILED with sub-status TIMEOUT. There may be a processing delay of up to 1 minute between when the timeout window elapses and when the status change is applied. The expiredAt field in the createTransaction API response reflects the exact expiry time.

Default behavior

If no custom timeout is configured, the workspace default is 2 hours (8 hours for cold workspaces). No action is required to maintain current behavior.

The following policy configurations extend the default expiry to 24 hours:

• A transaction policy with two-tier approval configured
• A transaction policy with a designated signer (API user or human) configured

In all cases, the expiry window begins when the transaction is created. If the required approval or signature is not completed within the window, the transaction transitions to FAILED with the substatus TIMEOUT.

Timeout layers

Fireblocks uses a three-layer timeout model. The most specific configuration always takes priority (e.g., Transaction-level > API-level > Workspace-level).

Signing edge cases

The timeout layer applied depends on who signs the transaction, not who initiates it.

Configuration limits

• Console: Enter values in minutes or hours using whole numbers only. Invalid ranges or non-integer values are rejected with an inline validation error.
• API: Pass the value in seconds. Invalid values result in a failed transaction.

Configure transaction timeouts

Workspace and API-level timeouts

1. In the Fireblocks Console, go to Settings > General > Transaction timeout.
   
2. Set your workspace-level default timeout. This applies to all transactions unless overridden.
3. Optionally, set an API-level timeout for flows where transactions are signed automatically by an API Co-signer.
4. Select Save configuration. All updates are subject to your workspace's quorum approval policy. The existing timeout configuration remains active until the change is approved.

Transaction-level timeout

To set a timeout on an individual transaction, pass the transactionTimeout parameter (in seconds) in the createTransaction API call. This value overrides both workspace and API-level configurations for that transaction.

For the full parameter reference, see the createTransaction endpoint in the Fireblocks API documentation.

Audit log

All timeout configuration changes are automatically recorded in the Audit Log. Each entry includes the user who made the change, the previous and new timeout values, and a timestamp. To view the Audit Log, go to Settings > Audit Log in the Fireblocks Console.

Best practices

• Use shorter timeouts for automated flows to improve security and reduce mempool congestion risk during high-volume bursts.
• Match the API-level timeout to your signing SLA. If your automation signs within minutes, a 2-hour workspace default is longer than necessary.
• Monitor for TIMEOUT failures. Subscribe to webhooks or poll the getTransactionById endpoint to detect transactions that fail with sub-status TIMEOUT, and build retry logic accordingly. For webhook event structure, see the Fireblocks webhook reference.

Frequently asked questions

Will this change affect my existing transactions?

No. The default 2-hour workspace timeout is preserved. Existing automations that rely on the current behavior will continue to work unless you change the configuration.

Can I set different timeouts for different asset types or vaults?

Not directly. The three layers (workspace, API, and transaction) are the available granularity. For per-transaction customization, use the transactionTimeout parameter in the createTransaction API call.

Is the expiredAt field available for all transactions?

Yes. The expiredAt field is included in the createTransaction API response and reflects the calculated expiry time based on whichever timeout layer applies.

What should I do when a transaction fails with TIMEOUT?

A TIMEOUT failure means the transaction was not signed and broadcast within the configured window. Because a timed-out transaction was never broadcast to the blockchain, there is no risk of duplicate submission when you recreate it. Recommended steps:

1. Check whether the signing step was missed (pending approvals, Co-signer availability).
2. Review whether your configured timeout is appropriate for your workflow.
3. Recreate the transaction. A timed-out transaction cannot be resubmitted.