Checking Correct Operation

Validators can check this dashboard to see whether they are executing Jito properly. Note, there is some lag since it requires a leader slot to confirm full functionality.

Correct operation can also be confirmed from the metrics emitted in the validator logfile. The exact datapoints depend on whether the validator is connected to the block engine or to BAM.

Healthy operation

block_engine_stage-stats is emitted once per second for as long as the block engine stream is up. Fields: num_bundles, num_bundle_packets, num_packets, num_empty_packets.

It stops entirely on disconnect rather than reporting zeros, so its absence is the disconnect signal.

On each successful connection you will also see block_engine_stage-connected, tagged with the url actually connected to.

Authentication

The validator periodically re-authenticates with the block engine. Authentication is handled inside the stage's one-second tick, and each datapoint is tagged with the url it applies to:

• block_engine_stage-tokens_generated — emitted infrequently, when a full set of auth tokens is generated (initial connection and each full refresh).

• block_engine_stage-refresh_access_token — emitted semi-frequently, when the access token is refreshed.

Troubleshooting

If the above lines aren't being emitted, look for the consolidated error datapoint block_engine_stage-proxy_error. It carries a cumulative count and an error string identifying the failure. Common values:

error value	Meaning
BlockEngineConnectionTimeout	Could not reach the block engine in time. Check the URL and network path.
BlockEngineConnectionError	Transport-level connection failure.
BlockEngineEndpointError	The configured URL could not be parsed or the TLS config is invalid.
AuthenticationConnectionTimeout / AuthenticationTimeout	Could not reach or complete the auth service handshake.
AuthenticationConnectionError	Also emitted when the validator identity changes at runtime.
AuthenticationError / BadAuthenticationToken	Auth token rejected or malformed.
GrpcStreamDisconnected	The packet or bundle stream ended.
BlockEngineConfigChanged	Block engine config was changed at runtime; the stage restarts.

One deliberate exception: AuthenticationPermissionDenied — meaning the validator is not on the leader schedule — is logged as a warning only and does not produce an error datapoint. This is expected on hot spares and on validators without active stake.

Block engine auto-configuration

The validator selects the most performant block engine region automatically unless --disable-block-engine-autoconfig is set. Failures here are a common cause of "not connected" and only surface under these names:

• block_engine_stage-autoconfig — the region selection result.

• block_engine_stage-autoconfig_ping — per-region latency probes.

• block_engine_stage-autoconfig_error — probe or selection failure.

• block_engine_stage-connect — connection attempts during the autoconfig flow.

BAM validators

When BAM is enabled, the block engine stage exits by design and does so silently — no error datapoint is emitted. block_engine_stage-stats legitimately disappears; this is not a fault. For a BAM validator, look instead for:

• bam_connection-metrics — emitted periodically while connected. Fields include bundle_received, bundle_forward_to_scheduler_fail, heartbeat_received.

• bam_manager-pubkey_error, bam_manager-identity_wait_err — startup and identity problems.

---

Note: As always, this code is expected to change. Please check core/src/proxy/block_engine_stage.rs and core/src/bam_connection.rs in jito-solana for the most up-to-date metrics.