Table of Contents

If after reviewing the following FAQs you are still unable to find a solution, are still experiencing issues, and/or have additional questions; please contact us at or via one of our other various methods. We are here to assist.

Where are the GroundRunner Logs stored?

To locate the GroundRunner log:

  • Click "Applications" near the lower-left corner

  • Select Admin

  • On the left-side panel, choose "Runners"

  • Locate the Runner concerning the inquiry

  • The file listed for "Install Location" is the GroundRunner

  • Follow the path to secure the GroundRunner

📓 As this file contains valuable information about what happens locally, there will be points in time when this file will need to be provided to OneCloud Support.

What is the difference between a OneCloud GroundRunner and CloudRunner?

The table below highlights some key feature differences between a GroundRunner and a CloudRunner.

OneCloud GroundRunner

OneCloud CloudRunner


Requires installation on a computing environment inside the corporate firewall that can interface with the external OneCloud service via port 443.



Microsoft Windows, Linux, macOS



Hosting, management and installation of the GroundRunner is the responsibility of the client.

OneCloud CloudRunners are a part of the overall OneCloud service, and therefore OneCloud's responsibility.

Data flow

With the use of a GroundRunner, no customer data will ever be transmitted through OneCloud's cloud service.

CloudRunners interface directly with supported cloud technologies. As such, data will be transmitted through OneCloud's service.

On-premise and
cloud integration

Yes - Full and seamless integration with both on-premise and cloud applications.

No - Integration only between cloud providers.

Native use of
applications APIs

Yes - Depending on the on-premise system, OneCloud BizApps will leverage different API interfaces and for cloud technologies, OneCloud will only use the published REST APIs that securely transmit data via HTTPS (TLS 1.2).

Yes - OneCloud BizApps only use the published REST APIs of the corresponding cloud provider that securely transmit data via HTTPS (TLS 1.2).

Installation instructions



Read the OneCloud Security Architecture white paper to learn more.

Why do I receive the error: "Failed to communicate with agent - this command was not executed"?

The network connection between the GroundRunner and the OneCloud service has been disrupted. This could be due to the fact that GroundRunner did not start or a network disruption between the OneCloud platform and the GroundRunner.

A OneCloud Chain or Command fails because it cannot cannot communicate with the OneCloud GroundRunner or CloudRunner. Often times when this happens you will receive the following message in the command log: "Failed to communicate with agent - this command was not executed".

To resolve the error please review the GroundRunner, check if the service is working and that there is a network connection to the internet from the server hosting the GroundRunner. If the issue is related to a CloudRunner, then please contact OneCloud support.

In some circumstances utilizing the timeout conditions of a Command can sometimes account for temporary network disruptions. More information about Command Error Handling can be found in this article on Error Handling.

I am on a trial and my GroundRunner fails to start?

If the OneCloud tenant is operating under a trial license, and that license has expired, then it is likely that the OneCloud agent will not start and yield the following error:

Your subscription to OneCloud has expired or your GroundRunner has been terminated. Please contact to resolve this issue.

To resolve this issue, simply remove the .expired file located where the OneCloud GroundRunner is installed and then restart the OneCloud GroundRunner.

📓 Valid Trial License Required!
If your OneCloud trial has expired, then as soon as you start your OneCloud GroundRunner, then a new .expired will be created. To extend your trial, please contact

Error "Unable to download resources associated with command. Please contact support if error persists"

Issue Summary

This error is often caused by Commands in a Chain using different runners that are not able to communicate with one another. While a CloudRunner is able to share its Outputs with a GroundRunner, a GroundRunner is unable to share its Outputs with a CloudRunner. For example, if the first Command in a Chain uses a GroundRunner and the second Command uses a CloudRunner and takes the Output of the first Command as an Input, then the Chain will fail.

Issue Solution:

Ensure the same runner is used across the entire Chain or that the communication flow is supported. That is, CloudRunner outputs can be used as Inputs to a Command using a GroundRunner but not the reverse.

Error Messages & Codes

Unable to download resources associated with command.

Why can I use a Command File Output from a CloudRunner on a GroundRunner, but not the opposite?

File Command outputs generated by the CloudRunner can indeed always be downloaded by a GroundRunner. However, OneCloud does not allow File Command outputs generated by the GroundRunner to be downloaded by a CloudRunner. This is to ensure that the on-premises data remains secure and does not inadvertently leaves the on-premises environment.

Additional Question Variations:

File Command outputs generated by a CloudRunner can be leveraged by the GroundRunner. How about using output that is generated by GroundRunner? Can this output be leveraged by the CloudRunner?

Can GroundRunners and CloudRunners exchange data?

Depending on the configuration of a OneCloud Chain, GroundRunners and CloudRunners can exchange data. Here is a quick overview:

Configuration / Setup

Resulting Capability

Two or more GroundRunners operating in the same

All Command outputs (including files) can be freely exchanged

GroundRunners operating on different networks

All Command outputs (including files) can be freely exchanged

GroundRunner to CloudRunner

Only outputs of type text, numeric, and list can be freely exchanged

CloudRunner to GroundRunner

All Command outputs (including files) can be freely exchanged

How do you remove old GroundRunners?


At this time, I can't seem to remove old GroundRunners that are no longer in use. Either the server they were on is gone or we are no longer using the server for OneCloud integrations. There should be an option for us to "force" delete a GroundRunners from the system. It seems that if the GroundRunners is inactive, it's not possible to delete it. Are there any options for mass deleting these GroundRunners today?


GroundRunners that are now longer active must be removed from all Connections in order to be deleted. Once you modify all the Connections to remove the reference to the retired GroundRunner, it can then be deleted.

What IP address does the CloudRunner originate from?

All requests from the CloudRunner originate from a single IP address:

If you are using an application that restricts access by IP address, whitelist this IP address to ensure the CloudRunner is able to communicate with your application.

Which ports need to be open for a GroundRunner?

The OneClould GroundRunner does not require any ports to be open. During the installation, by default, the configuration file has the listening portion disabled. If necessary to have the listener enabled, you will need to edit the GroundRunner config file and specify a PORT=. This allows GroundRunners on different servers to be able to share command outputs inside your corporate network.

How to test that a GroundRunner is listening and/or that it is accessible through a firewall/DMZ?

One of the hardest things to confirm and prove is the existence of something through a VPN, Firewall or DMZ. There are so many hidden devices at play that could come into the mix that make it complicated.

Here are some pointers to help narrow down the path to resolution:

  • Make sure the GroundRunner configuration is correct! Make sure that you have a GroundRunner PORT= specified. More information can be found on this in the Advanced GroundRunner Notes Configuration documentation.

  • If you haven't recently restarted the GroundRunner, go ahead and perform that action now to make sure it picks up that setting. Make sure to check if anything is running in the platform first.

  • Once the GroundRunner has been recently restarted, do a port listing on the server to see if it is successfully listening at the specified port. If you do not have anything listening at the specified port, then a deeper analysis will need to be performed.
    -- Windows: netstat -an | findstr 8821
    -- Linux/macOS: netstat -an | grep 8821

  • Once you have identified the listening port, you can attempt to telnet to the port. The GroundRunner is a light-weight HTTP client that is expecting input. BUT, if we do not supply input, an acceptable error will be presented if we just hit <enter>.
    -- Windows: telnet localhost 8821
    -- Linux/macOS: telnet localhost 8821

  • If the above tests perform as expected, perform the telnet test from a machine on the other end of the firewall/DMZ. The same response is expected. You will need to substitute "localhost" with the valid DNS name of the machine.

Depending on the various stages of your results you may need to engage your local IT/Infrastructure staff to assist and answer questions.

How long are GroundRunner logs retained and is this end-user configurable?

Currently the GroundRunner logs are retained for 168 hours (~7 days). Any log file (or compressed archive) older than 168-hours is purged. This option is currently not end-user definable.

How do I remove or disable a CloudRunner?

At present, CloudRunners may not be removed. However, since Runners work in conjunction with Connections a CloudRunner may be essentially disabled by not assigning it to a Connection.

  • Visit Connections from the left-side panel.

  • Find the Connection used and select the 🔽 on the right side

  • Choose "Edit"

  • In the "Runners" section, deselect "CloudRunner"

Did this answer your question?