Collect useful logs

Logs are most useful when paired with a short reproduction and a timestamp. Record what you expected, what actually happened, and the exact client/server versions before collecting them.

Enable client file logging

1. Open Settings, Advanced.
2. Enable Expert mode, then Developer mode. Logging controls appear in the developer section.
3. Set Log level to Debug and enable file logging. A level change alone does not create a file while file logging is off.
4. Reproduce the failure once and note the time and timezone.
5. Use the Log files actions to open the directory or export the archive. Restore your usual level afterwards.

Use Trace only when a maintainer needs it for a particular problem; it can produce substantially more output. Terminal logging is a separate sink and is not required for exporting saved file logs.

File names and export format

The current desktop logger writes date-stamped files named fancy-mumble.YYYY-MM-DD.log into the OS application log directory. Use View log files to find the actual path for your installation rather than assuming a hard-coded user folder.

Older files can be compressed to .log.zst. Export saved logs creates a Zstandard-compressed .log.zst archive, not a ZIP file. Keep the filename extension when attaching it. A missing directory before file logging is enabled is expected: the logger creates it when needed.

If export fails, record the displayed error and the destination path’s accessibility. Preserve existing logs; deleting them removes the failure evidence.

Correlate server logs

For the maintained Starling Compose deployment, collect the service relevant to the symptom:

docker compose ps
docker compose logs --since=10m gateway voice > voice-incident.log
docker compose logs --since=10m files > files-incident.log
docker compose logs --since=10m screenshare > share-incident.log

Use only the relevant command for your issue. Service names may differ in a customized Compose file. Include service exit/restart information from docker compose ps, and capture the first startup error for a service that never becomes healthy.

Starling uses Rust tracing. Set RUST_LOG=debug on the affected service and restart it when normal logs do not explain the failure. Return to normal logging after the reproduction. Do not apply legacy plugin INI log-level keys to Starling.

Review before attaching

Check for passwords, session tokens, private file URLs, personal messages, public IPs, and usernames you do not want to publish. Redact sensitive values consistently so related events can still be matched. Do not attach certificate private keys or entire data directories.

In the report, identify the start/end times of the reproduction and attach the screenshot of the affected controls alongside the logs. See Reporting bugs for an evidence template.