Troubleshooting

Organised by what you actually see. Find the message, not the cause.

Deploy is refused#

“Wasm binary is missing. Please compile your AssemblyScript code first.”#

Every deploy needs at least one compiled transform. Either you have no transform node at all, or you have one whose code was never compiled — saving the canvas does not compile it. Open the transform's code panel and compile, then deploy again. If the mapping genuinely needs no logic, add a pass-through transform to satisfy the check.

“Insufficient credits to boot worker.” (402)#

Your balance is at or below zero. Top up on the Credits page and deploy again. See credits & billing.

“A deployment operation is already in progress for this indexer.” (429)#

Only one deploy per indexer runs at a time. Usually this is a double-click and there is nothing to fix — wait for the first attempt to finish. If it persists for more than a minute, the earlier attempt is still resolving; check the logs before retrying.

“Indexer is already active or transitioning states.”#

You used a cold deploy on something that is already running. Use Republish instead — the button label changes to it automatically once the indexer is active, so seeing this usually means the page was showing a stale status. Reload and try again.

The retention limit message#

All ten version slots are full and every one is marked Keep Forever, so nothing can be evicted. Unprotect a version you no longer need, or delete one, from the Versions tab. See versions & rollback.

A wall of SQL you have to confirm#

Not an error — the destructive-schema gate. Your change would drop or narrow something in your database, so the exact statements are shown before anything runs. Read them. If the data loss is intended, confirm. If not, cancel and migrate incrementally: add the new column, deploy, backfill, then remove the old one later.

A URL is rejected#

Both your PostgreSQL connection string and your webhook destinations are checked against a guard that refuses hosts resolving to private, loopback, link-local or cloud metadata addresses. The worker runs in the cloud, so:

• localhost, 127.0.0.1, 10.x, 172.16–31.x and 192.168.x databases are unreachable and refused;
• a hostname that resolves to one of those is refused too — the check is on the resolved address, not the string;
• for local development, expose the service through a tunnel and use the public hostname.

The indexer deployed but is not healthy#

CrashLoop#

The pod starts and exits repeatedly. In order of likelihood:

1. The database is unreachable or the credentials are wrong. The startup lines in the logs will say so. Fix it with Edit & Redeploy.
2. The RPC endpoint is rejecting the connection. A missing, expired or rate-limited API key. Check the key on the indexer settings.
3. A transform faults on real data. It compiled, but it traps on an input it did not expect. The logs name the failure.

OOM Killed#

The worker exceeded its memory limit. Almost always a transform allocating without bound — building a large string per event, accumulating in a growing structure. Transforms should be stateless and allocate a fixed amount per event.

Image Pull Failed#

The runtime image could not be fetched. This is on the platform side, not your canvas. Retry the deploy; if it persists, the pinned runtime version may be unavailable — try the default runtime from the toolbar selector.

It is running but nothing is happening#

No rows in the database#

1. Check the logs first. A healthy worker with no per-event lines means nothing matched, not that writing failed.
2. Check the discriminator. The most common cause. A wrong instruction discriminator matches nothing; an account discriminator left empty when the account has an Anchor prefix decodes every field eight bytes early.
3. Check the account sequence number.If it points at the wrong position in the instruction's account list, you are decoding the wrong account.
4. Check the wires. A column with nothing feeding it gets nothing. The table node shows the source for each column.
5. Remember there is no backfill. An indexer only sees activity after it starts.

Values are wrong rather than missing#

This is a decoding problem, and it points at the field list. Borsh layouts are positional: one missing or misordered field corrupts everything after it. Compare your field list against the IDL or struct in order, and check the Data Sizereadout on the account node against the account's real size on chain — a mismatch confirms it.

If only large numbers are wrong, it is the type mapping: u128 narrows to u64, and a u64 can overflow BIGINT. Carry big values as strings into NUMERIC. See writing transforms.

Webhooks are not arriving#

1. Is the gate wired? A condition that returns false is working as designed. Temporarily disconnect it to confirm the sink fires at all.
2. Does your endpoint redirect? A 3xx is a failed delivery, not a hop — HTTP to HTTPS, or a bare domain to www, will fail every time. Configure the final URL.
3. Are you returning 2xx? Anything else is retried and then given up on.
4. Is your handler slow? A timeout counts as a failure and produces duplicates on retry. Acknowledge immediately and work asynchronously.

Signature verification always fails#

You are almost certainly hashing a re-serialised body. The HMAC covers the raw bytes as sent — capture the body before your framework parses it. The worked example is on the webhooks page.

WebSocket clients see nothing#

If the socket closes immediately, the connection key is wrong — it is validated before the upgrade. Copy it again from the node.

If the socket stays open but is silent, either the gate is filtering everything, or nothing has happened since you connected. Topics do not buffer: events published while no one was listening are gone. The durable copy is the row in your database.