Summary
Revisit the Settings > Gateway Logs experience so it is useful to both everyday users and technical troubleshooting workflows. The current raw live-log stream exposes implementation details without helping a nontechnical user understand whether the gateway is healthy, what went wrong, or what information to share with support.
The experience should present understandable diagnostics by default, retain raw logs as an advanced view, and provide a safe export function.
Current implementation
The current page:
- Renders gateway stdout and stderr directly in a fixed-height monospace log box.
- Continuously auto-scrolls as new output arrives.
- Provides only a Clear action.
- Stores logs only in renderer memory, so they are lost when the app closes.
- Silently trims the log buffer after it grows beyond 600 entries, retaining the newest 500.
- Does not provide timestamps, severity styling, search, filtering, pause, copy, or export.
This is useful as a developer console, but it is difficult for a nontechnical user to interpret and awkward to use when requesting help.
Proposed experience
User-friendly diagnostics
Make the default view a concise gateway health summary, including:
- Current status in plain language, such as Connected, Starting, or Needs attention.
- The most recent actionable warning or error with a suggested next step where possible.
- Basic troubleshooting actions such as reconnect or restart.
- The time of the latest status change or failure.
Raw live output should remain available under an Advanced logs disclosure rather than being the primary experience.
Advanced log viewer
Improve the raw-log view with:
- Timestamps and normalized severity levels.
- Visual distinction between errors, warnings, and informational messages.
- Search and severity filters.
- Pause/resume auto-scroll so users can inspect earlier entries.
- Clear indication when older in-memory entries have been discarded.
- Copy selected or visible logs.
Export diagnostics
Add an Export diagnostics action that creates a support-friendly file or bundle containing:
- Gateway logs for a defined recent period.
- Relevant app, gateway, OS, and configuration metadata needed for diagnosis.
- Gateway status, port, restart/failure information, and app version.
- A human-readable summary describing what the export contains.
The export flow must redact API keys, tokens, credentials, message content, personal paths, and other sensitive values. Before saving, tell the user what will be included and allow them to choose the destination. Use bounded retention or log rotation so useful diagnostics survive an app restart without unbounded disk growth.
Design considerations
- Use progressive disclosure: health and recommended actions first, technical detail second.
- Avoid presenting raw internal terminology as the only explanation of a failure.
- Make export discoverable from both the diagnostics page and relevant gateway error states.
- Clearly communicate privacy and redaction behavior.
- Preserve enough raw detail for engineering investigations without requiring users to take screenshots.
- Localize all summaries, actions, empty states, and export messaging.
Acceptance criteria
- Nontechnical users can understand the gateway's current state without reading raw logs.
- Raw live logs remain available in an advanced view.
- Users can search or filter logs and pause automatic scrolling.
- Users can export a diagnostics package to a chosen location.
- Exported diagnostics contain useful timestamps and environment metadata.
- Known credentials and sensitive values are redacted before export.
- Diagnostics remain available across an app restart for a documented, bounded retention period.
- Existing gateway startup and error reporting continue to work.
Summary
Revisit the Settings > Gateway Logs experience so it is useful to both everyday users and technical troubleshooting workflows. The current raw live-log stream exposes implementation details without helping a nontechnical user understand whether the gateway is healthy, what went wrong, or what information to share with support.
The experience should present understandable diagnostics by default, retain raw logs as an advanced view, and provide a safe export function.
Current implementation
The current page:
This is useful as a developer console, but it is difficult for a nontechnical user to interpret and awkward to use when requesting help.
Proposed experience
User-friendly diagnostics
Make the default view a concise gateway health summary, including:
Raw live output should remain available under an Advanced logs disclosure rather than being the primary experience.
Advanced log viewer
Improve the raw-log view with:
Export diagnostics
Add an Export diagnostics action that creates a support-friendly file or bundle containing:
The export flow must redact API keys, tokens, credentials, message content, personal paths, and other sensitive values. Before saving, tell the user what will be included and allow them to choose the destination. Use bounded retention or log rotation so useful diagnostics survive an app restart without unbounded disk growth.
Design considerations
Acceptance criteria