Reporting a problem

When something is wrong on a gateway, one download usually answers every question support would otherwise have to ask for one at a time: the diagnostics package.

Send this

1. Open the CloudManager UI on the device: http://localhost:5004.
2. On the Status page (or the Logs page), select Download Diagnostics. It takes a few seconds — the button says Generating… while it collects from every service.
3. Send us the resulting Capture.Edge.Diagnostics-<gateway id>-<date>-<time>.zip.
4. Add three sentences: what you expected, what happened instead, and when (a rough UTC time is enough — it is what lets us find the right lines in the log).

That is the whole ask. Everything below explains what is in the file and what to do when you cannot produce one.

Treat the package as a credential

It contains the gateway's full configuration — and the configuration holds passwords. Replicator and edge-bus passwords are stored encrypted, but local database, sync destination and connection credentials are stored in plain text, so they are in the package in plain text too. It also carries the gateway id, every address and every log file. Environment variables whose names look like secrets are redacted, and nothing else is.

Send it over the channel you would use for a password, never to a public issue tracker or a shared drive, and rotate anything you are not comfortable having shared.

---

What is in it

The zip has one folder per Capture service — CloudManager, Collector, Syncer, Analytics — each containing:

File / folder	What it holds
Logs/	That service's log directory, including the error-only files and startups.log. See Logging.
Info.json	Everything the service is currently reporting: connection states, sync progress, real-time sync, cloud connection, active issues, issue history. The same data the UI's View Raw JSON shows.
IssueList.json	The issues active at the moment the package was generated.
IssueHistory.log	Every issue raised and cleared since that service last started, oldest first, as plain text lines you can read against the log timestamps. See Issues.
ProcessInfo.json	The process: which executable, its commit hash, when it started, and its memory, thread and handle counts.
SystemInfo.json	The machine: OS, architecture, .NET version, processor count, whether it runs in Docker, the clock and time zone, and the environment variables (values of secret-looking names are redacted).
PerformanceMetrics.json	Garbage-collection and thread-pool statistics — what to look at when a service is slow rather than broken.
FileSystemInfo.json	Every drive with its free space, plus the temp, working and logging directories — the first thing to check when writes are failing.
NetworkInfo.json	Host name and every network interface with its addresses and state.

The CloudManager folder additionally holds:

File / folder	What it holds
Config.json	The configuration the gateway is running right now.
ConfigBackups/	The whole backup directory, so the configuration history comes along. See Config Backups.
DataStore/	CloudManager's local databases (.db), which hold the stored configuration and version history.
identity.guid	The gateway id this device authenticates with.

A missing folder is itself a finding

CloudManager collects from the other three services over HTTP. If one of them is not running or not answering, its folder is simply absent from the zip rather than the download failing — so a package with no Collector folder says the Collector was down.

---

If you cannot download the package

Take what you can, in this order:

1. Logs — Download Logs on the same page gives the log files without the rest. Or copy them from disk; the paths are in Logging.
2. Configuration — http://localhost:5004/api/config/GetConfig, or a file from the backup directory.
3. Gateway id — C:\ProgramData\Capture\identity.guid on Windows, /etc/capture/identity.guid on Linux.

If CloudManager itself is not running, the log files on disk are the whole story. Include errors<yyyyMMdd>.log as well as the main log: it has a longer retention, so it often still covers a problem that started days ago.

---

What to look at first yourself

Symptom	Where to look
Anything at all is wrong	The Issues page in the CloudManager UI. See Issues.
Data is collected but does not reach the cloud	Status page: the Syncer's sync progress, and the cloud connection line for each service.
Nothing is being collected	Status page: the Collector's connection list, and its values-per-minute.
The gateway cannot authenticate	Authentication failures.
A configuration change made things worse	Config Backups — compare against the previous configuration before restoring it.
The device cannot reach the cloud at all	Cloud connect requirements.

The commit hash is on the first line of every log file

It identifies the exact build the gateway is running, which is more precise than a version number when a fix is being confirmed. startups.log carries the same information for the last 1000 service starts.