> For the complete documentation index, see [llms.txt](https://docs.zigiwave.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zigiwave.com/operations-and-monitoring/logs.md).

# Logs

ZigiOps generates logs at multiple levels to help you monitor integration activity, diagnose failures, and perform deep-level debugging when needed. This page explains the types of logs available in ZigiOps, where to find them, how to configure logging behavior, and how to use logs effectively in day-to-day operations.

### What types of logs does ZigiOps produce?

ZigiOps produces three categories of logs. Each serves a distinct purpose and is accessible from a different location in the platform.

| Log Type         | Location in UI                                   | What It Contains                                               | Primary Use                                                               |
| ---------------- | ------------------------------------------------ | -------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **Activity Log** | Workflow page (Activity field, top-right corner) | Executed actions, polling cycles, listener events, sync status | Monitor workflow execution and confirm successful operations              |
| **Error Log**    | Troubleshooting page                             | Failures, exceptions, rejected records, API errors             | Diagnose integration errors and failed action runs                        |
| **Debug Log**    | General Settings (toggle) + log files on disk    | Detailed internal trace of every operation step                | Deep diagnostics; enabled temporarily when standard logs are insufficient |

{% hint style="info" %}
The Activity Log records what happened at the workflow level. The Error Log captures what went wrong. The Debug Log records why it went wrong, at the internal operation level. Enable Debug only when you are actively investigating an issue.
{% endhint %}

### Where are the ZigiOps log files stored on disk?

In addition to the in-UI logs, ZigiOps writes log output to files on the host machine. The file locations depend on the operating system where ZigiOps is installed.

#### Windows

```
ZigiOps\platform\logs
```

#### Linux

```
ZigiOps/platform/logs
```

#### ZigiWave-Hosted Cloud

For Cloud-hosted deployments, log files are managed by the ZigiWave team. You do not have direct file system access. Use the in-UI Activity Log, Error Log, and the Troubleshooting page to review integration activity. Contact ZigiWave Support if you need raw log output from a cloud instance.

### What log levels are available and how do I change them?

ZigiOps supports the following log levels. The active log level determines how much detail is written to the log files and visible in the platform.

| Log Level | When It Is Active                    | Verbosity | When to Use                                                       |
| --------- | ------------------------------------ | --------- | ----------------------------------------------------------------- |
| **INFO**  | Default (always on)                  | Standard  | Normal operations; records key events and action outcomes         |
| **DEBUG** | Manually enabled in General Settings | High      | Detailed tracing for troubleshooting; disable after investigation |

#### How to enable Debug log level

Debug log level is disabled by default. To enable it:

{% stepper %}
{% step %}
**Open General Settings**

Open the ZigiOps web console and navigate to General Settings.
{% endstep %}

{% step %}
**Go to the Debug section**

Scroll to the Debug section.
{% endstep %}

{% step %}
**Enable Debug Log Level**

Toggle on **Enable Debug Log Level (Overall)**.
{% endstep %}

{% step %}
**Save the settings**

Save the settings. The log level will change to DEBUG immediately, without a restart.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
Debug log level significantly increases log verbosity and disk usage. Enable it only for the duration of your investigation, then disable it and return to the default INFO level. Leaving DEBUG enabled in production environments is not recommended.
{% endhint %}

### How do I configure log data collection and purging?

ZigiOps can collect additional HTTP and payload data to support troubleshooting. This data is not collected by default and must be enabled in General Settings. Once enabled, it appears on the Troubleshooting page alongside the standard action run phases.

The following settings control data collection and how long the data is retained before it is automatically purged.

| Data Type    | Default Purging Setting | Where to Configure                              |
| ------------ | ----------------------- | ----------------------------------------------- |
| HTTP Data    | Configurable interval   | General Settings > Debug > HTTP Data Purging    |
| Payload Data | Configurable interval   | General Settings > Debug > Payload Data Purging |
| Status Data  | Configurable interval   | General Settings > Debug > Status Data Purging  |

{% hint style="info" %}
Collected HTTP and payload data is retained only for the configured purging interval. After that interval, the data is deleted automatically. This behavior is by design: ZigiOps does not store transferred data permanently. Adjust the purging interval based on how long you need the data available for investigation.
{% endhint %}

#### How to enable HTTP and payload data collection

{% stepper %}
{% step %}
**Open General Settings**

Navigate to General Settings > Debug.
{% endstep %}

{% step %}
**Enable HTTP data collection**

Toggle on **Collect HTTP Data** to enable HTTP request and response capture.
{% endstep %}

{% step %}
**Enable payload data collection**

Toggle on **Collect Payload Data** to enable payload capture.
{% endstep %}

{% step %}
**Set purging intervals**

Set the purging interval for each data type to match how long you need to retain the data.
{% endstep %}

{% step %}
**Save the settings**
{% endstep %}
{% endstepper %}

### How do I download a support file with log data?

ZigiOps allows you to export a support file that packages troubleshooting data for one or more integrations. This file is useful when escalating an issue to ZigiWave Support, as it gives the support team the context needed to diagnose the problem without requiring direct access to your instance.

The support file is generated from General Settings > Download Support File. The following options are available when generating the file:

| Option                      | Description                                                                       |
| --------------------------- | --------------------------------------------------------------------------------- |
| Troubleshooting Data toggle | Includes troubleshooting data from the selected integrations in the exported file |
| Integrations selector       | Choose which integration(s) to include in the support file                        |
| Past "N" Days               | Select how many days of historical data to include                                |

#### How to generate and download a support file

{% stepper %}
{% step %}
**Open General Settings**

Open the ZigiOps web console and navigate to General Settings.
{% endstep %}

{% step %}
**Go to the Download Support File section**

Scroll to the Download Support File section.
{% endstep %}

{% step %}
**Enable troubleshooting data**

Enable the **Troubleshooting Data** toggle.
{% endstep %}

{% step %}
**Select integrations**

Select the integrations to include.
{% endstep %}

{% step %}
**Choose the time range**

Set the number of past days to include.
{% endstep %}

{% step %}
**Download the file**

Click the **Download** button to generate and save the file.
{% endstep %}
{% endstepper %}

### What are the best practices for managing logs?

* Enable Debug log level only during active investigations. Disable it as soon as you have the data you need.
* Set purging intervals for HTTP and payload data to match your investigation window. Longer retention means more disk usage.
* Check the Activity Log after every major workflow change to confirm the integration is behaving as expected.
* Use the Error Log as your first stop when an integration stops producing expected output. It will show the most recent failures with timestamps and error details.
* Before contacting ZigiWave Support, generate a support file with troubleshooting data for the affected integration. This reduces back-and-forth and speeds up resolution.
* Review log file disk usage periodically on self-hosted deployments, especially if Debug mode was left enabled longer than intended.

### Where can I go from here?

The following pages are closely related to the topics covered on this page:

* **Troubleshooting:** Step-by-step guidance for diagnosing and resolving integration issues using the Troubleshooting page in ZigiOps
* **General Settings:** Full reference for all configurable platform settings, including the Debug section
* **Scaling and Load:** How to size and scale your ZigiOps deployment to handle higher data volumes and maintain log performance under load
* **Best Practices for Building Integrations:** Guidelines for keeping integrations reliable and maintainable, including operational hygiene


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.zigiwave.com/operations-and-monitoring/logs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
