“Probe across multiple regions”

Symptom

Users in different regions report different retrievability. You want to confirm whether the issue is geographic (network-side) or isolated to specific clients.

Diagnose

Multi-vantage is the whole point. Run with --bee pointing at nodes in different regions:

bee-check <ref> \
  --bee https://us-east.bee.example \
  --bee https://eu-central.bee.example \
  --bee https://ap-south.bee.example \
  --gateway https://api.gateway.ethswarm.org \
  --output json | jq '.vantages | map({bee_url, retrievable, elapsed_ms, proximity_to_root})'

What to look for in the output:

• Same status across all vantages. Probably a content-level issue (lost, garbage-collected, never pushed) — region isn’t the axis.
• partial with a regional pattern. US says yes, EU says no. Drop into --per-chunk from the failing region — likely a neighborhood-level retrieval problem rooted in that region’s peering.
• All slow but eventually yes. Long latencies (multi-second) with the same status — likely overloaded chunks of the manifest; cross-reference with chunk_stats.per_neighborhood.

Useful: target-overlay framing

If you have a specific user’s overlay (or you know their gateway’s overlay), pass it as --target-overlay. The report sorts vantages closest-first to that overlay and tags each with target_proximity:

bee-check <ref> --target-overlay <user-overlay-hex> --bee ... --bee ...

The closest vantage to that overlay is your best proxy for “what the user actually sees”. A retrievable from a near vantage but unretrievable from a far one is a strong signal that the user’s network position is the problem, not the content.

Fix

Diagnosis-only — fixes depend on what you find. Common follow-ons:

• Stale stamps → Re-seed from an old batch.
• Not-yet-pushed → My upload looks lost.
• Specific neighborhood unreachable → escalate to whoever runs Bee nodes in that neighborhood (or run one yourself).