CONNACK 3 (0x03) — Connection Refused: server unavailable

The broker is reachable at the network level but declines to service the connection — it is starting up, shutting down, or over capacity.

Start free MQTT / Sparkplug B → canonical

Diagnosis

When you hit this

Connecting during broker startup, before it finishes loading a large persistent session store.
The broker hit its configured connection limit.
A cluster node that is up but not yet joined, so it refuses rather than serving stale state.

Resolution

How to fix it

Retry with exponential backoff
Unlike codes 1, 2, 4 and 5, this one is genuinely transient. Back off rather than reconnecting in a tight loop.
Check the connection limit
Broker connection caps are commonly hit after adding a fleet of devices that each open more than one connection.
Confirm cluster health
In a clustered broker, a node in the process of joining refuses connections while it syncs.

Normalization

What Forge does about it

This is a transport failure, so there is nothing for Forge to normalize: the reading never arrives. What Forge does is refuse to let the gap look like good data. The read-time dropout check flags a field that fell to zero and recovered as a communication glitch rather than a real measurement, and the stuck-sensor check fires when a value repeats for 20 consecutive readings — which is what a cached or last-known value looks like after a link drops. Forge does not retry or reconnect for you; that is your client's or your gateway's job.