People talk about flashy frameworks, IDEs, and now AI copilots as the ultimate tools for developers. But I think logs hide real superpowers that we often overlook. They’re like truth serum you give to your apps, and they will reveal their secrets. Because they track every action, error, and alert, digging into logs can save you from embarrassing bugs and help you catch issues before they crush end-users’ systems.
Logs provide valuable insights into a program’s activities. Typically, logs offer various severity levels, ranging from detailed step-by-step records to general overviews of the software’s execution during log generation. This data aids us in analyzing software, performance, and security issues. It is important to note that log files rarely provide the exact reason for an issue in plain text. Instead, log analysis is used to understand and diagnose problems by reconstructing events.
There are multiple types of logs and storage locations. We will focus on application-type logs stored locally or locally like, meaning without the use of a dedicated logging system or log management software.
How are the log files structured in io.Connect?
We use:
- log4js for our JavaScript-based code
- log4net for our .NET components
log4js is a powerful logging library for Node.js, based on the Java log4j framework. It supports various flexible and configurable log levels and appenders.
The log4js library offers flexibility because its behavior and settings are controlled through JSON configuration files (rather than being hardcoded). We use file and console-type appenders, but you can also use various custom appenders (learn how here io.Connect Desktop Documentation - Configuration > System)
Additionally log4js allows log message formatting and filtering.
log4js appenders:
| Appender Type | Description | Use Case |
|---|---|---|
| File Appenders | Writes logs to files on the disk. | Primary appender in io.Connect Desktop. |
| Console Appenders | Writes logs to the console. | Useful for debugging and development. |
| FTP Appenders | Writes logs to a remote FTP server. | Useful for centralized logging. |
log4js log levels:
A log level is the severity or priority of a log event (debug, info, etc). Whether an appender will see the event or not is determined by the layout.
We use the following layout:
Format Example
[<DATE>] [<LEVEL>] [<COMPONENT>] - [<MESSAGE>]
- DATE: The timestamp of the log entry. Provides the context of when the event occurred.
- LEVEL: The severity level of the log entry (e.g., DEBUG, INFO, WARN, ERROR, FATAL). Indicates the importance and urgency of the message.
- COMPONENT: The part of the application generating the log.
- MESSAGE: The actual log message. Describes the event or error being logged.
Note: .NET logs also include [<THREAD-ID>].
Defaults settings
- Log files roll over when they reach a certain size (10MB in io.cd case).
- A maximum of N rolled-over log files are kept (5 in io.cd case).
- Oldest log files are deleted when the limit is reached.
- Can be configured via %LocalAppData%\interop.io\io.Connect Desktop\Desktop\config\logger.json
Important:
- Interop.io does not log sensitive data. We only log what the software is executing.
- The timestamps in the log file reflect the time of the machine on which the application is running.
Tools for Log Analysis
Logs are formatted to be compatible with simple text editors like Notepad, as well as more complex solutions like Splunk, and everything in between, depending on your choice. As a bare minimum, we recommend using Notepad++ for log analysis and working with .json files.
- Basic editors: Notepad, Notepad++, JSON formatters
- Advanced: Splunk, Graylog, Datadog, etc.
Log Files Overview
Application log
The application.log file is the main log generated by the Electron application, which drives the logic, applications, windows, layouts, etc, for io.Connect Desktop. This file should usually be the starting point in the analysis process.
Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs
<ENV>-<REG> - represents the environment and region of io.Connect Desktop (e.g., DEMO-INTEROP.IO)
Bridge log
The bridge.log file is the log file of the .NET component in io.Desktop, responsible for the logic behind the windows (not to be confused with the OS).
Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs
Gilding log
The gilding.log file is generated by gilding.exe, a tiny .NET application used for starting and tracking the lifetime of the main io Application. This way gilding.exe can collect logs in case the main .exe crashes.
Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs
Getway log
The gw.log file logs the activities of the message bus of io.Connect Desktop. In the current version, it is written in Node.js (was written in Java in the past).
Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs
Installer log
The installer.log file is created by io.Connect Desktop during installation.
Default location: %LocalAppData%\interop.io\io.Connect Desktop\Installer
Adapter logs
The adapters logs are generated by the various adapters, like Outlook, Word, Excel, etc.
Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\ApplicationAdapters
Application-specific logs
The application-specific logs are written by the applications participating in the io.Connect Desktop. You can use the API-s to log messages.
Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs\applications
Important: application-specific logs are not to be confused with the Electron application.log.
From 9.9 onward you can funnel a web app’s own uncaught errors, console messages and failed network requests into the shared application.log (under <installation_location>/interop.io/io.Connect Desktop/UserData/<ENV>-<REG>/logs) so frontend events sit in the same timeline as platform activity.
Learn how to enable and configure it here - io.Connect Desktop Documentation - More > APIs
Extra: Crash reports
io.Connect Desktop can automatically capture crash dumps whenever any of its processes crashes.
Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs\crashes
The feature can be turned on by adding the crashReporter block to system.json:
{
"crashReporter": {
"enabled": true,
"companyName": "Your Company",
"productName": "Your Product",
"folderPath": "%LocalAppData%/interop.io/io.Connect Desktop/crashes",
"output": {
"type": "local" // local | server | backtrace
}
}
}
Output types
| Type | Behaviour |
|---|---|
| local | Writes .dmp files under /reports. |
| server | POSTs the crash payload to the REST endpoint set by serverUrl. Use this to forward dumps to io.Manager or a custom service. |
| backtrace | Sends the report to a Backtrace instance (supply backTraceConfig). |
Example for sending dumps to io.Manager:
{
"crashReporter": {
"output": {
"type": "server",
"serverUrl": "http://localhost:4356/api/crashes"
}
}
}
Dump‑file maintenance
Add an optional dumps object under output to control retention:
{
"crashReporter": {
"output": {
"dumps": {
"limit": 10,
"deleteOnSent": true
}
}
}
}
- limit – maximum number of dump files kept between restarts.
- deleteOnSent – remove a dump after successful upload instead of archiving to /sent.
Reviewing Log Files – Best Practices & Use cases
- Identify session boundaries and total number of runs.
- Confirm version and environment metadata.
- Review the full system configuration.
- Trace warnings/errors across log sets.
- Analyze each process from start to finish, across rolled-over logs if necessary.
- Identify the user environment.
System log rotation
Starting with io.Connect Desktop 9.3 you can tell the platform what to do with older logs on startup. The setting lives under logging.files in system.json and lets you keep your log folder clean without scripting a clean‑up job.
| onStartup value | Effect | Good for |
|---|---|---|
| keep (default) | Leave yesterday’s files alone. | Workstations where disk isn’t an issue. |
| delete | Remove the whole log folder before new session starts. | Locked‑down VDI or demo pods. |
| archive | Move files to moveOldTo or default archive path. | Debugging long‑running issues across days. |
See how to configure it here: io.Connect Desktop Documentation - Configuration > System
In the next article, we’ll share some use cases and frequently used keywords that can help find useful information.