Multi-vantage and “partial”

Every --bee URL you pass becomes one row — a vantage — in the report. A vantage probes the reference independently and contributes one outcome: retrievable, unretrievable, or error (where error means the call itself failed before we got an answer).

The report’s top-level status aggregates them:

Public gateway probes (--gateway) are folded into this same aggregation — a “yes” from any gateway counts the same as a “yes” from any Bee.

What partial actually means

partial is the most interesting outcome. It says: the reference is retrievable from some perspectives in the network but not others. This is often fine (Swarm is a distributed network; not every node has visibility into every chunk’s neighborhood) but it can also be a leading indicator of:

• Asymmetric pinning — only one node has the content pinned and the chunks haven’t propagated yet.
• A specific neighborhood being slow or unreachable — combine with --per-chunk to see which chunks are missing where.
• Postage batch staleness — chunks whose batch is expiring can start to disappear from the neighborhood that was storing them.

Picking your vantages

The signal you get is only as good as the perspectives you sample. A useful baseline:

• one node you control (lets you see network-retrievability from your own infrastructure)
• one node in a different geographic region (catches “it works here but not from EU” cases)
• one public gateway (--gateway https://api.gateway.ethswarm.org — proxies a retrieval through a gateway operator’s nodes)

For the public gateway probe, see also Comparison to check.ipfs.network — a “yes” from the gateway is the closest analog to “yes from the network” that you’ll get without operating fleets yourself.

See also

• Swarm docs — Public gateways
• Bee API — GET /bzz/{ref}/