Issues
Every Capture Edge service reports what is currently wrong with it — a PLC it cannot reach, a mapping that does not resolve, a local database that is refusing writes, a queue that is dropping points. The Issues page in the CloudManager UI collects all of it in one list.
Open http://localhost:5004 on the device and select Issues. The menu entry carries a badge with the
number of active issues, so you can see from any page whether something needs attention.
Older Capture Edge versions report problems only in the log.
Active issues
One row per problem, worst first, and within a severity the one that started most recently first.
| Column | Meaning |
|---|---|
| Severity | Error — a connection is down, or nothing is being collected, stored or synced at all. Warning — one part is not working (a single mapping, variable or measurement) while the rest carries on. Info — worth knowing about; nothing is degraded. |
| Where | The service reporting it, and the component inside it — usually the connection or database by name. |
| Problem | What is wrong, in words. |
| Category | Which configuration page it belongs to: General, Local storage, Collector, Replicator, ADS router, Syncer, Analytics, Cloud manager, Edge bus, Variables, Triggers. This is the tab to open to fix it. |
| Since | When the issue first became active. |
| Last checked | When the service last confirmed the issue is still there. |
An issue clears itself when the underlying problem goes away — a reconnected PLC, a mapping that now resolves — so an empty list means the services currently have nothing to report, not that nobody looked.
If a service is down, it cannot report that it is down. The page says so above the list — "Collector is not answering, so anything wrong there is not in this list" — and that line is the finding.
The list refreshes every 10 seconds; Refresh forces it.
History
Below the active list is what has been raised and cleared since each service last started: when an issue appeared, when it changed, when it cleared, and how long it had been active.
This is what answers "it was broken this morning and it is fine now, what happened?" — an outage that has recovered leaves nothing in the active list but a pair of rows here.
| Column | Meaning |
|---|---|
| When | How long ago the transition happened (for example 5 min ago). Hover the value for the exact date and time, in your browser's local time. |
| What happened | Became active, Changed or Cleared. |
| Where | The service and the component. |
| Issue | What the problem was. |
| Was active for | On a Cleared row, how long the issue had lasted. |
It starts at the service's last restart and keeps the most recent 500 changes per service. A restart empties it — so a short history is not evidence that nothing has gone wrong.
Where else the issues turn up
- The Capture portal. Each service publishes its active issue list to the cloud, so the gateway's page in the portal shows the same problems without anyone opening the local UI.
- The log. Every issue is also logged when it is raised, so a problem that has already scrolled out of memory is still in the log files.
- The diagnostics package. Each service folder carries
IssueList.json(active at the moment of download) andIssueHistory.log(the whole in-memory history as plain text, oldest first). That makes the history readable next to the service log's own timestamps, and it is why the package is worth downloading while a problem is still happening.