Logs & status
The live log stream and what each of the eight indexer statuses means.
The Logs tab is the live output of your worker pod, streamed over a WebSocket. Recent history is loaded first, then the tail continues in real time — there is no refresh button because there is nothing to refresh.
Indexer statuses#
There are eight. The first four are normal; the last four mean the worker is not running.
| Field | Type | Description |
|---|---|---|
| stopped | shown as “draft” | No worker is running. This is where every indexer starts, before its first deploy. |
| deploying | transitional | A deploy is in flight. The pod is being created or replaced. |
| active | healthy | The worker is running and streaming. This is the state you want. |
| paused | not running | The worker is not consuming. |
| error_crashloop | CrashLoop | The pod started and then repeatedly exited. Usually a runtime failure — an unreachable database, or a transform that faults on real data. |
| error_memorylimit | OOM Killed | The worker exceeded its memory limit and was terminated. Usually a transform allocating per event without bound. |
| error_imagepull | Image Pull Failed | The runtime image could not be fetched. This is a platform-side problem rather than something in your canvas. |
| error_unknown | Failed | The deploy failed for a reason that does not fit the categories above. |
Reading the stream#
Lines carry a timestamp and a level. Three kinds are worth recognising:
- Startup lines — schema migrations applied, the validator connection established, the Wasm module loaded. If these do not appear, the worker never got as far as streaming.
- Per-event lines — decoded transactions and rows written. Their absence on a healthy worker usually means the program is quiet, not that something is broken.
- Errors — database write failures, transform faults, failed webhook deliveries.
Duplicate lines are removed as history and the live tail meet, so the hand-off is not visible to you.
Deploy dividers#
Each redeploy inserts a labelled divider into the stream, and arriving from the canvas after a deploy draws one at that moment. When you are asking “did my change take effect?”, everything below the most recent divider is the new version.
Pod health#
Health is pushed over the same socket rather than polled, so a pod that fails to start surfaces immediately — with the reason, for cases like a failed image pull or a startup timeout. Before this was pushed, a broken deploy could sit on “Deploying” indefinitely; now it resolves to a real error status.
Actions from this page#
- Download logs — the current buffer as plain text, for attaching to a bug report or grepping locally.
- Edit & Redeploy — opens the indexer settings and deploys in one step. This is the fastest fix for a wrong database URL or a bad RPC key, which are the two most common causes of a crashloop.
- Redeploy — from the failure banner, once you have fixed the cause.