Introduction
Use the Co-signers page to check connection status, review running instances, and identify configuration issues without contacting support.
To access the co-signers page on the Utila web console, click Vault Settings > API > Co-signers.
Monitor co-signers
Summary cards
At the top of the page, two cards give you a vault-wide snapshot:
Co-signers shows the total number of co-signers detected, with a breakdown by status (for example, "7 connected · 2 offline"). Click either status to filter the list.
Pending signatures shows the total number of transactions waiting to be signed across all co-signers in this vault.
Above the cards, the timestamp shows when the data was last refreshed. Click Refresh to fetch the latest data.
Co-signer list
Each row in the co-signer list shows one co-signer, its connection status, the number of pending transactions assigned to it, and the number of active instances detected.
Connected means the co-signer is active and picking up transactions as expected.
Offline means no instance has polled recently. This may indicate the process has stopped, the host machine is unreachable, or a configuration issue such as an IP allow list issue.
The list is sorted with Connected co-signers first, followed by Offline, alphabetically within each group.
Note: Only co-signers that have been active in the past 3 days appear in this list. If a co-signer is not visible, it may not have run recently enough to be detected. To set up a new co-signer, use the link in the empty state or refer to the co-signer setup guide.
You can filter the list by connection status using the filter controls above the list.
Viewing instances
Click the arrow (>) to expand any co-signer row to see the individual processes running under it. Each row in the instance list represents a single running process - two processes on the same device or machine appear as separate instances if they were started separately.
Each instance shows:
Column | Description |
Instance ID | A unique identifier for this process. |
Device ID | The device this instance is running on. Click to open the device detail page. |
Last seen | Shows Connected if the instance polled within the last 5 minutes. If the period is longer, it shows the elapsed time with a warning indicator. Hover for more context. 
|
OS | The operating system of the host machine. |
Source IP | The IP address the system saw during the connection. This may differ from the local machine IP if the host is behind a proxy or NAT. |
CLI Version | The version of the co-signer CLI this instance is running. |
Possible notices
Only one instance running
If only one instance is running, a notice at the bottom of the instance list reminds you to consider deploying a second instance for redundancy. Running a single instance means there is no failover if the host goes down.
There are two types of redundancy:
Runtime redundancy - a second process running on a different machine, using the same device. Quick to set up, no approvals needed.
Device redundancy - a second device with its own independent key share. Requires vault admin quorum approval and may take longer to set up, but provides stronger security isolation.
If more than 10 instances were detected in the active lookback window, the list shows the 10 most recent with a note that more exist.
CLI version
If any connected instance is running an older version of the CLI, a notice appears at the top of the page.
The notice only appears when a connected instance is outdated. Offline instances with old CLI versions do not trigger it.
Action menu
The 3-dot action menus is at the right end of each co-signer row.
Copy service account ID for use in API calls or CLI commands.
View service account to open the SA settings page (only shown when the SA is in the same vault).
View devices to open the device detail page.
What you see if there are no co-signers
If no co-signers have been detected in this vault, the page shows a setup prompt with a link to the co-signer setup guide.
Troubleshoot using the co-signer page
Check whether a co-signer is running after deployment
After deploying a new co-signer, open this page to confirm the instance appears as Connected with a recent Last seen timestamp. You can verify the correct device is visible in the instance list and check that the CLI version matches what you installed - without needing to run a test transaction.
Investigate why transactions are not being signed
If transactions are accumulating in AWAITING_SIGNATURE, check the co-signer status first:
Co-signer is Offline - the process has likely stopped or the host is unreachable. Restart the co-signer process and confirm the instance appears as Connected.
Co-signer is Connected but backlog is growing - the co-signer is not the root cause. See the two scenarios below.
Co-signer is connected but a specific transaction is not moving
A co-signer only picks up transactions where it is set as the designatedSigner. If a co-signer is connected and signing other transactions but a specific one never moves, check the designatedSigner field on that transaction in the Transactions page. If it is empty or set to a different service account, the fix is on the transaction creation side, not the co-signer.
Co-signer is connected but the overall backlog keeps growing
If the co-signer is active but the total pending count is climbing, a published transaction may be blocking subsequent nonces from the same wallet. Go to the Transactions page, filter by AWAITING_SIGNATURE, and look for the oldest transaction in the queue to identify what may be causing the blockage.
Diagnose an IP allow list misconfiguration
If a co-signer goes offline after a server migration or IP change, the cause is often an IP allow list configured on the service account that no longer includes the host machine's outbound IP.
The co-signer produces no error when blocked by an IP allow list. The only signal is the absence of polling activity. To investigate:
Open the service account settings for the co-signer (available from the actions menu).
Find the configured IP allow list.
Compare it against the outbound IP of the machine running the co-signer process.
Update the allow list if there is a mismatch.
Check for redundancy gaps
If the instance footer shows "Only 1 instance running," your co-signer has no failover. If that host goes down, transactions will stop being signed until the process is restarted. Consider deploying a second instance on a separate machine. See the redundancy note above for the difference between runtime and device redundancy before deciding which approach to take.
Identify outdated CLI versions
If the CLI version notice appears, expand individual co-signer rows and check the CLI Version column to identify which instances are running older versions. Coordinate an upgrade for those instances.
Key terms
Co-signer - A tool that allows you to sign transactions automatically by accessing a secure private key share. It runs as a CLI process on your own infrastructure, authenticates as a service account with the Signer role, and signs any transaction in the vault where it is set as the designated signer.
Instance - A single running process of the co-signer CLI. Multiple instances of the same co-signer can run in parallel from different machines for redundancy. The page detects instances from backend polling activity.
Designated signer - The field on a transaction that specifies which service account must sign it. A co-signer only picks up transactions where it is set as the designated signer. Transactions without this field are not picked up automatically.
Connected - At least one instance polled the API within the last 5 minutes.
Offline - No instance has polled the API in the last 5 minutes.
Related articles