Support Bundle
The Support Bundle button on the Settings → Logs page lets deployment owners download a diagnostic .zip in one click, so a customer issue can be reproduced and debugged without shell access to the server.
Who can generate a bundle
Same restriction as the Logs page: only deployment owners — anyone who is an Owner of at least one organization in this deployment. Organization-level admins and viewers cannot generate one.
The organization-specific sections of the bundle (db_state.json, job_history.json, plugin_health.json) are scoped to only the organizations you own — an owner of Org A does not see Org B’s job history or plugin configuration, even if Org B also exists on this deployment. Host info, server configuration, and the log buffer are deployment-wide (see below), matching the Logs page.
What it contains
The zip has seven files — six JSON documents plus a plain-text log dump:
| File | Contents |
|---|---|
manifest.json | Generation timestamp and bundle format version |
host_info.json | OS, kernel, CPU count, memory, uptime, app version, git commit, Rust compiler version, plus whether the server runs in a container and its effective CPU/memory limits (deployment-wide) — see Reading host info |
config.json | Effective server configuration, with the database URL reduced to host name only and the JWT secret reduced to a configured/not-configured flag (deployment-wide) |
logs.txt | The most recent entries (up to 5,000) from the in-memory log buffer, one line per entry in the same timestamp LEVEL target message format as the Logs page (deployment-wide, not scoped to your orgs) |
db_state.json | Latest applied schema migration and connection-pool stats for the control database and every organization you own |
job_history.json | The most recent background job executions (sync, summary generation, etc.) per organization you own, with error messages truncated to 500 characters to bound how much of an upstream error response (which may embed request details) ends up in the export |
plugin_health.json | Per-source enabled/disabled state and last-sync timestamp for each organization you own. Config fields are allowlisted for export — only known-safe operational fields (base URLs, feature toggles, etc.) are included; secrets are reduced to a configured/not-configured flag, and any field not on the allowlist (including a newly added one not yet reviewed) is omitted entirely |
Reading host info
When TeamGlimpse runs in a container, some values in host_info.json describe the machine the container runs on rather than the container itself. This is not a bug in the export — the underlying operating-system counters are simply shared with the host. Knowing which is which matters, because a server that ran out of memory can otherwise appear to have had plenty free.
in_container tells you how to read the rest of the file:
in_containerisfalse— every value describes the server directly. Nothing further to consider.in_containeristrue—kernel_versionis the host’s kernel,uptime_secsis how long the host has been up (not the server process), andcpu_count/total_memory_bytesare the whole machine’s. The values that describe what TeamGlimpse actually had available arecontainer_cpu_limit(in CPU cores) andcontainer_memory_limit_bytes.os_nameandos_versiondescribe the container image.
Either limit may be null, meaning no cap was set and the server could use the whole machine.
platform tells you whether those fields could be filled in at all. Container detection and CPU/memory limits are Linux mechanisms, so on windows or macos they are always absent — null there means “not measurable on this platform”, not “no limit was set”.
So if the server was killed for running out of memory, compare its usage against container_memory_limit_bytes — not total_memory_bytes.
Privacy and security
Treat a support bundle exactly as you would shell access to the server. The log buffer is deployment-wide and can include operational details — error messages, sync timestamps, job failures — from every organization on the deployment, not only your own. Secrets (API tokens, the database password, the JWT signing secret) are redacted before the zip is built, but the bundle is still sensitive. Do not share it with anyone who should not see deployment-wide diagnostics, and delete local copies once support has what they need.