This guide helps you identify, diagnose, and resolve common issues related to the Celigo on-premise agent (OPA). It serves as a reference for system administrators, support engineers, and developers who manage or rely on OPA-based connections to integrate on-premise systems with cloud applications.
When to use this guide:
-
The on-premise agent appears offline or unresponsive in integrator.io.
-
Flows using OPA-based connections fail or stall unexpectedly.
-
You're installing, upgrading, or migrating the OPA and encounter errors.
-
You need to verify OPA configuration, logs, network access, or token issues.
-
You want to perform preventive checks or validate OPA readiness after environment changes, such as an OS upgrade or firewall rule updates.
Legacy production and sandbox licenses
In legacy Production and Sandbox environments, changes in one environment affect both environments. The Production and Sandbox environments share the same underlying resources. Any resource you create, edit, or delete in one environment is immediately reflected in the other.
This includes connections, imports, exports, flows, scripts, and API tokens. Use caution when editing resources in either environment.
This behavior doesn't apply to accounts on the multi-environment license, where each environment maintains its own isolated resources.
Migrations from the legacy Production/Sandbox license to the new multi-environment license are underway. Your account has not migrated to the new multi-environment license if you can toggle between environments.
Follow this checklist to ensure that the on-premise agent's base configurations are correct. If you've completed the checklist and your OPA isn't working as expected, continue to follow the troubleshooting steps in this article.
-
Confirm that the OPA is running locally
Windows:
-
Press
Win+R, typeservices.msc, and hit Enter. -
Locate Celigo Agent in the list.
-
Validate that the OPA's Status is 'Running' and the Startup type is 'Automatic'.
– OR –
Linux:
Run the following command:
systemctl status celigo-agent. The status should be 'Active (running)'. -
-
Check your network connectivity
-
Test your network's outbound access to
https://api.integrator.iousing the following curl command:curl -I https://api.integrator.io. -
Confirm that your firewall allows outbound port 443 (HTTPS). If your firewall is behind a proxy:
-
Windows: Check → → .
-
Linux: Check the following environment variables:
HTTP_PROXYandHTTPS_PROXY
-
-
-
Verify the OPA's token configuration: You must verify that the OPA's token in your on-prem server and integrator.io are identical.
Windows:
-
In your Windows server, navigate to
C:\Users\<user>\AppData\Roaming\Agent\and open the Settings file. -
Note the OPA's token.
-
In your browser, navigate to integrator.io and sign in.
-
Click → → .
-
Compare the OPA tokens.
Linux:
-
Execute the
sudo cat /root/.config/agent/Settingscommand. -
Search the Settings file for the OPA's token.
-
In your browser, navigate to integrator.io and sign in.
-
Click → → .
-
Compare the OPA tokens.
-
-
Confirm your OPA's version
Windows:
-
In your server, navigate to → → .
-
Find Celigo Agent in the list.
-
Your OPA version must be 3.7.0 or later. If you haven't updated your OPA, it isn't receiving automatic updates, which may be causing your issues.
Exception
Celigo has ended support for users running Windows Server 2012 R2 with the Celigo on-prem agent. If your server is on this Windows version, you must download agent version 4.3.0. Failure to do so will trigger automatic updates that will break your on-prem agent configuration and cause your flows to fail. Note that version 4.3.0 does not support automatic updates since Celigo has ended support for Windows Server 2012 R2.
Linux:
If you're using the packaged version, run:
sudo find / -type f -name "*.log" 2>/dev/null | sudo xargs grep -i "latest version" 2>/dev/null.If not, check the version in the Linux OPA logs by running:
journalctl -u celigoagent.service -n 1000 -f. -
-
Validate connection settings
In integrator.io, open an OPA-based connection verify the following:
-
Your connection is using the correct OPA.
-
The Base URI is reachable from the OPA host (ex,
localhostor the target system's IP address).
-
-
Review logs (optional for early signs)
Follow the steps below to inspect the OPA logs in either Windows or Linux operating systems. If the logs are not available, check for missing or empty log files.
Windows:
-
Open the Celigo Agent in your Windows server.
-
Click View logs.
-
Search for:
-
Connection errors
-
Authentication failures
-
Unexpected restarts or shutdowns
-
– OR –
-
Navigate to
C:\Users\<user>\AppData\Roaming\Agent\. -
Search for
server-{{Current Date timestamp}}and open the corresponding file. -
In the logs, search for:
-
Connection errors
-
Authentication failures
-
Unexpected restarts or shutdowns
-
Linux:
-
Open your terminal.
-
Run
journalctl -u celigoagent.service -f. -
Review the logs for:
-
Connection errors
-
Authentication failures
-
Unexpected restarts or shutdowns
-
To review a large number of older logs, use
journalctl -u celigoagent.service -n 1000 -f. You can increase and decrease the number "1000" to retrieve more or less log data. -
Once these checks are complete, if the issue persists, move on to targeted troubleshooting steps (ex, connection errors, failed flow execution, network misconfigurations).
In some cases, deleting the existing OPA and installing a new one can solve an unknown issue.
Delete the existing OPA and install a new one:
-
Uninstall the OPA as a service through the Task Manager.
-
Press
Win + R, typeservices.msc, and hit Enter. -
Locate Celigo Agent in the list and stop the service.
-
Navigate to the OPA UI and uninstall the service.
-
-
Open the Task Manager and end all running OPA-specific tasks.
-
Open the Control Panel and uninstall the OPA.
-
Delete all existing OPA installers and updaters from the User folder.
-
Install a new OPA using the steps in Integrate data through firewall with Windows on-premise agent.
Delete the existing OPA and install a new one:
Important
The commands must be executed in the listed order.
-
Stop the OPA:
sudo systemctl stop celigoagent.service -
Remove the service:
sudo rm /etc/systemd/system/celigo-agent.service -
Delete old OPA files:
rm -rf /path/to/old-agent-folder -
Install a new OPA using the steps in Integrate data through firewall with Linux on-premise agent.
There are some common errors that can be fixed without assistance from the Celigo Support team.
There are generally three reasons why the OPA is offline in integrator.io. Before contacting Celigo Support, check the following:
If these are all working as expected, check your logs for any of the common errors and solutions listed below. If none of the errors appear, contact Celigo Support.
Issue: In some cases, the OPA won't automatically upgrade when a new version is released.
Root cause and Solution: This occurs if the OPA isn't running as a service or if you're missing administrator privileges (Windows only).
Exception
Celigo has ended support for users running Windows Server 2012 R2 with the Celigo on-prem agent. If your server is on this Windows version, you must download agent version 4.3.0. Failure to do so will trigger automatic updates that will break your on-prem agent configuration and cause your flows to fail. Note that version 4.3.0 does not support automatic updates since Celigo has ended support for Windows Server 2012 R2.
Issue: Can't find logs or the log files are empty.
Root cause: You may have an OPA running with incorrect permissions, or a misconfigured or inaccessible log path.
Troubleshooting: Determine if the log files exist.
Windows:
-
Navigate to
C:\Users\<user>\AppData\Roaming\Agent\. -
Search for
server-{{Current Date timestamp}}. -
If the logs are missing entirely, delete and reinstall the agent.
Linux:
Logs are created in the /root/.config/agent/ folder of your Linux machine.
-
Use this command to determine if log files exist in your root directory:
sudo find / -type f -name "*.log" 2>/dev/null -
If the logs are missing entirely, delete and reinstall the agent.
Issue: You may encounter the following pop-up error dialog when using the Celigo OPA, particularly after an automatic update.
Error: Failed to uninstall old application files. Please try running the installer again.: 2
Root cause: This issue is typically triggered when the Windows system PATH environment variable is in a corrupted or inconsistent state following the OPA's auto-update process.
Solution: Restart the system. A full Windows restart often resolves the issue, as the operating system will attempt to automatically repair or reload critical environment variables (such as the PATH variable) during startup.
Symptom: The Celigo on-prem agent service is not running in the Services application.
Root Cause / Additional Information: The on-prem agent can be executed in three modes:
-
Through the OPA UI – When launched directly from the desktop, the OPA runs with a visible user interface.
-
Run in Background – When this option is enabled, the UI is hidden, but the OPA continues running in the background. It can be verified via Task Manager.
-
As a Windows Service – The OPA can be installed and run as a Windows service.
Warning
Only one instance of the OPA can run at a time. Once the service is installed through the UI, it is important to close the UI completely before attempting to start the OPA.
If the service fails to start or stops unexpectedly, determine if the OPA is running in Background mode or via the UI. Ensure that the OPA is not running and terminate running instances before restarting the service.
In some cases, the OPA's heartbeat could fail during normal operations. Heartbeats are sent periodically (approximately every 60 seconds). Long gaps between heartbeat logs could indicate the OPA stopped or lost connectivity. There are several potential causes for failed heartbeats:
-
The OPA process isn't running
-
You have an expired or invalid access token
-
There are network connectivity issues
-
A firewall or proxy is blocking the OPA
-
The OPA crashed or hung
-
There's a time skew between the OPA and the server
To determine if your OPA is functioning properly, check your logs (Windows, Linux). Use a text editor or command-line tool (grep, findstr) to find success or error logs.
A successful heartbeat can appear with any of the following success log messages:
-
[INFO] Heartbeat sent successfully -
[INFO] Agent heartbeat acknowledged by integrator.io
A failed heartbeat can appear with any of the following error log messages:
-
[ERROR] Failed to send heartbeat: Connection timeout -
[ERROR] Unable to reach https://api.integrator.io -
[ERROR] Invalid token while sending heartbeat -
[ERROR] Socket timeout during heartbeat -
level=error, logName=heartbeatFailed, err=Error: getaddrinfo ENOTFOUND api.integrator.io at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26) { errno: -3008, code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'api.integrator.io' }
If you find any of the above errors, check the logs again to determine if the OPA was able to connect to a tunnel. Successful tunnel messages usually look as follows:
-
2025-05-06T12:08:22.172Z: level=info, logName=tunnelCreated -
2025-05-06T12:08:23.346Z: level=info, logName=tunnelReadyForUse
If your log isn't able to connect to a tunnel, it could mean that the server was not able to establish a connection to the Internet. Check for the following entries in the logs:
-
level=error -
logName=noInternet
If noInternet appears, inspect nearby log entries for: heartbeatFailed. If both noInternet and heartbeatFailed are logged around the same time, it strongly suggests a network connectivity issue on your machine or server. There are generally two causes for network connectivity issues:
-
Temporary Network Glitch: Your server may experience a brief loss of internet connectivity — lasting anywhere from a few seconds to a minute. These are typically self-resolving.
-
Instance Resource Limitations (eg. AWS EC2): If you're using a low-tier EC2 instance such as
t2.micro,t3.micro, ort3.small, it may be hitting:-
Network bandwidth limits
-
Packet per second (PPS) caps
-
CPU credit exhaustion
-
Sample logs:
level=error, logName=heartbeatFailed, err=Error: connect ETIMEDOUT 72.44.45.92:443
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1300:16) {
errno: -4039,
code: 'ETIMEDOUT',
syscall: 'connect',
address: '72.44.45.92',
port: 443
}
level=error, logName=requestTunnel, requesting tunnel failed
error={"errno":-3008,"code":"ENOTFOUND","syscall":"getaddrinfo","hostname":"api.integrator.io"}
You can expect to see this log error approximately three times before the OPA connects to the tunnel, since sometimes the OPA tries to switch ports to find a free one. It may be an issue with Celigo's infrastructure if it's happening often and and in continuous intervals, leading to the OPA appearing Offline (red) in integrator.io. There are several other potential causes:
-
Temporary network instability: Brief network hiccups could cause occasional connection failures.
-
Server load fluctuations: If the server experiences periodic high load, it might occasionally reject new connections or fail to bind ports.
-
Stale connections are not being cleared quickly: If the system doesn't immediately free up ports from closed connections, we can hit these stale ports occasionally.
-
Race conditions leading to stale ports assignment.
To determine if your OPA is functioning properly, check your logs (Windows, Linux). Use a text editor or command-line tool (grep, findstr) to find the following log:
2025-05-01T22:59:50.176Z: level=error, logName=forwardInError, code=undefined, message=Unable to bind to 0.0.0.0:7017, stack=Error:
If you see the logged error, contact Celigo Support.
If you are using on-prem JDBC connections, make sure JDK 17 is installed.
For Oracle database on-premise connections, the Oracle instant client must be installed on the user's computer.
In some cases, you'll need to use the OPA logs to search for uncaught exceptions or other errors. An uncaught exception is an error that occurs during program execution but is not handled by any try/catch or equivalent exception-handling mechanism in the code. As a result, the program typically terminates abnormally, and a stack trace is often printed or logged to indicate where the error occurred. Uncaught exceptions can occur due to:
-
File descriptor or memory limits
-
Out of Memory (OOM): A condition where a system runs out of memory resources, leading to failures in executing processes. This situation often results in the operating system terminating processes to reclaim memory, which can cause unexpected crashes or degraded performance in applications. OOM conditions are typically associated with memory leaks or unbounded resource retention, which can impact system stability.
-
Missing environment variables
Sometimes the error isn't found in the OPA's logs. In those cases, you'll need to analyze your system-level logs.
A stack trace is a report that provides information about the active stack frames at a specific point in time during the execution of a program. It is typically generated when an exception or error occurs and helps developers understand the sequence of function or method calls that led to the failure. Stack traces will often show:
-
The file name & line number of the source.
-
The function or method involved.
-
Whether it's during: startup, token validation, request forwarding, etc.
All of this data can be used to resolve your errors or sent to Celigo Support if you are unable to resolve them on your own. You can find stack trace errors easily in either Windows or Linux using the steps below:
To find your OPA's logs and analyze uncaught exceptions:
-
Navigate to
C:\Users\<YourUsername>\AppData\Roaming\Agent\. -
Open the log folder.
-
In the Settings file, find
uncaughtExceptionHappenedOnServiceand determine if it's set toTrue. -
Open the
uncaughtExceptionfile.
-
-
Search for common keywords, preferably using a log viewer or CLI tool. You can also use commands if you don't want to use your native search feature.
Command:
Select-String -Path "C:\Users\<User>\AppData\Roaming\Agent\logs\agent.log" -Pattern "exception","error","uncaught","stack"Common keywords:
-
Uncaught Exception -
UnhandledPromiseRejection -
TypeError -
ReferenceError -
SocketTimeoutException
-
To check for system-level triggers, use the Windows Event Viewer to search for:
You can also use PowerShell commands like: Get-EventLog -LogName System
Logs are created in the /root/.config/agent/ folder. To find your OPA's logs and analyze uncaught exceptions:
-
Use this command to determine if log files exist in your root directory:
sudo find / -type f -name "*.log" 2>/dev/null -
If the files exist, use this command to open the logs:
~/.agent/logs/– OR –
Open the files directly from the OPA directory.
-
Open the Settings file by executing
sudo cat /root/.config/agent/Settings.-
Find
uncaughtExceptionHappenedOnServiceand determine if it's set toTrue.
-
-
Search the log file for common keywords, preferably using a log viewer or CLI tool. You can also use commands if you don't want to use your native search feature.
Command:
sudo find / -type f -name "server-{{Current Date timestamp}}.log" -exec grep -iE 'exception|error|uncaught|stack' {} + 2>/dev/nullExample command:
sudo find / -type f -name "server-2025-07-29.log" -exec grep -iE 'exception|error|uncaught|stack' {} + 2>/dev/nullCommon keywords:
-
Uncaught Exception -
UnhandledPromiseRejection -
TypeError -
ReferenceError -
SocketTimeoutException
-
-
In the returned search list, find the following log entries:
-
uncaughtException
-
To check for system-level triggers, execute any of the following commands: /var/log/syslog, /var/log/messages, dmesg.
After uninstalling the OPA service, you may get an uncaught exception error and your OPA may crash. The error will include Error: EPERM: operation not permitted, unlink.
To uninstall the OPA service properly after receiving this error, click Uninstall service again in the OPA UI.
You can create a support ticket at any time, but we especially recommend it if you run into any of the following:
-
An uncaught exception isn't self-explanatory.
-
The OPA crashes immediately after start.
-
The issue is reproducible but not logged clearly.
Before you contact Celigo Support, gather:
-
If there is an uncaught exception, retrieve the
uncaughtExceptionfile. -
OPA version
-
OS details
-
Flow or connection details that trigger the error
How many instances of an OPA can I set up?
You can run only one instance of the OPA on a machine. However, the same OPA can be used to allow integrator.io to talk to multiple databases and applications on the same network as the OPA.
Does the on-premise agent need to be installed on the same machine as the system to be integrated?
Typically, OPAs can be installed on any machine within the same network as the server running the system to be integrated. However, there can be exceptions such as when setting up a JDBC connection.
Which IP addresses does the on-premise agent use to communicate with integrator.io?
The OPA uses several IP addresses to communicate with integrator.io. If you need to open up outbound traffic for an OPA running in your environment:
-
Whitelist the integrator.io IP addresses for the US or the EU for the HTTPS protocol.
-
Whitelist the agent-extension server IP addresses for the US or the EU for the SSH protocol.
How can I reopen the on-premise agent window and make changes, after it's set to run in the background?
Most OPA installations choose to Run in background, in which case the program, On-Premise Agent – integrator.io, is not visible in the Windows taskbar. To restore the OPA user interface and make changes or view activity logs, double-click the program's shortcut.
How can I keep my on-premise agent from stopping unexpectedly?
To stop your OPA from closing unexpectedly, use a small and dedicated Windows server, then run the agent in the background. We recommend you don't use that machine for anything else, though you technically can.
Will there be any difference to my entitlements when I move from current setup to multi-environments?
Resources are not shared between environments. A new OPA needs to be configured for each non-production environment after migration.
It depends on which environment setup your account uses.
Legacy Production/Sandbox: If your account is on the legacy Production/Sandbox license, resources — including on-premise agents — are shared between your Production and Sandbox environments. You can use the same OPA for connections in both.
Multi-environment: If your account has migrated to the multi-environment setup, environments are fully isolated by design and resources cannot be shared across them. Each environment — Production, Dev, Sandbox, or any other non-production environment — requires its own agent instance, created separately under → → . Each instance generates its own unique token and must be installed independently.
If you're migrating from a legacy Sandbox to multi-environment: Your existing OPA will not carry over to the new non-production environment. After migration, you'll need to create and configure a new agent for each non-production environment.