How do you get support-grade telemetry from customer environments that restrict or forbid outbound data — and what do you do when you get nothing?

Design for the strictest customer first and everything else is easy. The ladder: (1) full telemetry (metrics/logs/traces to your cloud) for customers who allow it; (2) metadata-only — health, versions, feature usage counters, no payload data; (3) heartbeat-only — liveness and version, enough to know who's dangerously behind; (4) dark — nothing leaves without a human decision. For tiers 3-4, the diagnostic bundle is your lifeline and deserves product-level engineering: a single support-bundle command gathering logs (with PII redaction filters), effective config (secrets stripped), component versions, resource/health snapshots, and recent-error summaries into one archive with a manifest — designed so the customer's security team can review it, because they will. Redaction must be allowlist-shaped (collect known-safe fields) rather than blocklist ('remove things that look secret'). Operationally: version the bundle format, test it in CI against every release (a broken collector discovered during a Sev-1 is a disaster), and train support to request the bundle as step one, not step five. The interview-level insight: telemetry is a trust negotiation — showing customers exactly what leaves (open-source the collector, provide the manifest) expands what they'll consent to.