How to collect logs for Support

Logs help Support identify the root cause quickly. This guide explains:

• what to share,
• what you can safely redact,
• and how to format logs so they’re actionable.

What Support needs (and why)

Support typically needs:

• Timestamps: to correlate events and identify when the failure started
• Error messages: to detect known failure patterns
• Version information: to map to known issues and fixes
• Recent changes: to narrow down what triggered the issue

What you can redact

You may redact or mask the following:

• Hostnames and internal domains
• IP addresses (unless the issue is explicitly network-related)
• Usernames and email addresses
• Tokens, API keys, passwords, private keys, certificates, secrets
• Customer-specific identifiers

Tip: Replace sensitive values with placeholders (for example, REDACTED_HOST, REDACTED_TOKEN) instead of removing entire lines. Context around an error often matters.

What to collect

Choose the option that fits your environment:

Option A (preferred): Support bundle / log bundle
If your environment provides a log bundle export, attach it to your ticket.

Option B: Targeted log excerpt
If a bundle isn’t available, paste/attach:

• the last 100–200 lines of the most relevant logs, and
• include the time window (example: “10:20–10:30 UTC”).

How to paste logs into a ticket (best practice)

When adding logs to your ticket, include:

• Time window and timezone
• Any repeated error line(s)
• Whether the VM was restarted (and when)

Example (sanitized):

• “Errors started at 2026‑02‑24 10:24 UTC”
• “Repeated message: connection timeout to REDACTED_HOST”
• “VM restarted at 10:28 UTC; issue persisted”

If you cannot share logs

If you cannot share logs due to confidentiality:

• Share the exact error message(s) you see
• Share last known good time + what changed recently
• Let Support know whether a screen-share is possible and under what constraints