When you’re troubleshooting robots in production, the last thing you want is to chase log files across multiple machines, services, and containers.
In IBM RPA environments, logs are essential for understanding failures, investigating incidents, and validating behavior during development and testing. Local log files still have their place, but they are not always the best option when you need a single place to search, filter, and monitor logs in real time.
That is where Grafana and Loki come in.
With this new capability, IBM RPA logs can be sent to Grafana Loki and visualized in Grafana, giving teams a centralized and near real-time view of what is happening in their automation environment.
In this post, I’ll walk through what Grafana and Loki do in this scenario, how the integration works, how it can be configured, and how it can help RPA teams during troubleshooting and monitoring.
Why Grafana + Loki for RPA logs?
Grafana is a popular platform for dashboards and observability, and Loki is its log database. Loki is often described as “Prometheus for logs”: instead of indexing the full log content, it indexes labels such as application name, environment, or other metadata, which makes it efficient and practical for log exploration.
For IBM RPA, this gives us:
-
A centralized log view across multiple components and services
-
Near real-time troubleshooting during incidents or test runs
-
Custom dashboards for errors, execution patterns, or test markers
-
Flexible filtering by application, environment, or scenario
Instead of opening multiple local log files, operators and support teams can investigate everything from a single interface.
How the integration works
At a high level, IBM RPA components generate log events and send them to a Loki endpoint, which can then be queried and visualized in Grafana.
From a connectivity perspective, this integration supports three common options:
This gives customers flexibility to choose the model that best fits their environment, from simple local setups to more secure enterprise-style deployments.
Choosing how to connect to Loki
The Grafana/Loki integration can work in three different ways, depending on how simple or how secure you want the connection to be.
For quick local setups, HTTP is usually enough. If you need encrypted traffic and username/password protection, you can use HTTPS with Basic Authentication.
And for stronger security requirements, you can use HTTPS with mutual TLS (mTLS), where the client must present a valid certificate.
For the secure options (HTTPS and mTLS), the recommended approach is to place a reverse proxy in front of Loki. We recommend Nginx for this. This is especially useful because Loki does not natively provide the user/password-style configuration needed for the Basic Authentication scenario.
How to configure it
The integration can be configured in two ways:
-
Through the module configuration using the LogConfig key
-
Through environment variables for sensitive values such as credentials, certificate paths, and certificate passwords
Configuration via LogConfig
The logging configuration is defined in the module’s .config file, inside appSettings, using the key LogConfig.
The Grafana appender supports the following options:
Here is a simple example of each of scenario discussed before (HTTP, HTTPS and mTLS):
HTTP
A simple option for local development or demos:
<add key="LogConfig" value="info grafana buffer=1 gzip connectionString="url=http://localhost:3200"" />
HTTPS + Basic Authentication
A good choice when you want encrypted traffic and basic access control:
<add key="LogConfig" value="info grafana buffer=1 gzip unsecure connectionString="url=https://localhost:3443;user=lokiuser;password=lokipassword"" />
HTTPS + mTLS
A stronger option where the client also authenticates with a certificate:
<add key="LogConfig" value="info grafana buffer=1 gzip unsecure connectionString="url=https://localhost:3445" clientCertificatePath="C:\client.pfx" clientCertificatePassword="1234"" />
When using self-signed certificates locally, it is important to configure the endpoint and certificates correctly. In an mTLS scenario, there are two trust relationships to keep in mind:
Once those pieces are aligned, Grafana can successfully connect to the secure Loki endpoint.
Environment variables for sensitive values
For security reasons, sensitive values can also be provided via environment variables, so they do not need to be stored directly in the .config file.
For the Grafana/Loki integration, the following environment variables are supported:
For Application Insights, the relevant variable is:
This is especially useful in containerized deployments or environments where secrets should be managed outside the application configuration.
Important: if the same setting is provided both in the .config file and through environment variables, the .config value takes precedence.
What the main options mean
A few of the Grafana appender options are particularly useful to understand:
buffer
This defines how many log events are grouped before sending them to Loki.
For demos, tests, and live troubleshooting, buffer=1 is usually the best choice.
gzip
Enables GZip compression for requests sent to Loki.
This can be useful to reduce payload size, especially when logs are sent in larger batches.
unsecure
Skips TLS certificate validation.
This is mainly intended for local environments using self-signed certificates. It should not be used in production unless there is a specific and well-understood reason to do so.
clientCertificatePath / clientCertificatePassword
These are used for mTLS scenarios where the endpoint requires a client certificate.
This allows the connection to be authenticated with a certificate instead of (or in addition to) username/password-based protection.
Does this replace existing logging?
No. This capability does not replace existing logging options.
File logging, SQLite logging, and Application Insights can continue to be used as before. Grafana/Loki is simply an additional destination that improves centralized visibility.
This means teams can adopt the feature gradually without losing their current logging workflows.
Final thoughts
Adding Grafana Loki support gives IBM RPA users a modern and practical way to monitor logs in real time.
It helps teams move from isolated, local logging to a more centralized and searchable observability model, while still supporting different security levels such as HTTP, HTTPS + Basic Auth, and mTLS.
For customers already using Grafana, this makes log analysis much easier. For teams that need better visibility into their automations, it opens the door to dashboards, live monitoring, and faster troubleshooting.
In short, this capability helps turn logs into something much more useful: a real operational tool.