Collect Signal Logs and a Support Package

Inspect, copy, and securely send Signal diagnostics with the evidence support needs.

Written By 4ALL.LIVE

Last updated 1 day ago

Collect Signal diagnostics that preserve the failing stage while giving you a deliberate inspection point before anything is shared with support.

Best for: operators escalating a reproducible Signal failure after recording the event, language, pipeline stage, and time of occurrence.

Understand runtime diagnostics

Runtime diagnostics are held in memory only. They are shown newest first and capped at 200 entries. Closing or relaunching the application can remove memory-only evidence, so inspect and copy relevant entries before relaunching when safe.

Clear Logs removes the current runtime diagnostic entries. Do not clear them until the required evidence has been reviewed and captured under the production team's policy.

Build the support package

  1. Reproduce the issue only when it is safe and the approved fallback is available.
  2. Record the approximate time, event and language, pipeline name, source state, output device and channel, and the first stage where the result differs from expectation.
  3. Open Logs and inspect the newest relevant entries.
  4. Open the support-package preview.
  5. Review every included section before choosing to send.
  6. Send in app only as an explicit action. A successful submission returns a support reference ID; record that ID for follow-up.

Inspect the preview

The preview can include account, organization, device, audio, pipeline, operating-system and application, license, and updater metadata. A field marked redacted does not make the overall package anonymous. Inspect the complete preview in the context of your organization's sharing policy.

Security boundary: tokens and keyring contents are excluded. Never add or send them separately.

In-app sending accepts a package up to 5 MB. If the package exceeds the limit, reduce only nonessential diagnostic material while preserving the relevant failure evidence, then review the preview again.

Verify the package

  • The failure time and first affected stage are documented.
  • The preview contains enough device, graph, status, and application context to reproduce the issue.
  • No credential-vault, token, or unrelated sensitive content has been added.
  • The package is no larger than 5 MB.
  • The returned support reference ID is saved with the incident record.

Troubleshoot collection or sending

  • Relevant logs missing: avoid clearing or relaunching before capturing memory-only entries on the next safe reproduction.
  • Package too large: preserve the relevant time window and metadata, remove only unrelated material, and reinspect.
  • Send fails: confirm network access and retain the inspected evidence without exposing it through an unapproved channel.
  • No reference ID: do not assume submission succeeded; keep the package and retry only through the approved support process.

Operational note

A support package is diagnostic evidence, not proof of hardware compatibility, RF performance, or an LL-TTS service-level result. Continue using the approved production fallback while support investigates.