> For the complete documentation index, see [llms.txt](https://docs.rierino.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rierino.com/quick-start/debugging-with-rierino.md).

# Debugging with Rierino

Built-in testing and debugging features give you visibility across all deployments

Rierino includes several built-in helpers that make development and debugging easier, such as AI development agents and expression and template validators. For structured, end-to-end debugging beyond these, there are two main approaches: **audit runs** and **log monitoring**.

## Audit Runs

Audit runs are recommended for development environments. They let you review the inputs, outputs and error stack traces of a saga flow step by step.

You can run audits in two ways.

### Through API

Any gateway channel or path configured to allow auditing can be called through the special `/api/test` endpoints (for example, `/api/test/rpc/Ping`). These calls offer two things that regular `/api/request` endpoints don't:

1. **Unmodified payloads:** The request body is passed to backend services exactly as sent. This lets you imitate payloads from users or internal systems.
2. **Step-by-step details:** With the `rierino-audit-path` header, the response includes the input, output and metadata of every step executed in the saga flow, plus a short stack trace for any errors.

{% hint style="info" %}
If the backend service is configured to store audit results, the audit details are also saved in the database.
{% endhint %}

### Through Saga UI

If you'd rather not debug through code, the Saga UI gives you tools to run different audit scenarios and inspect how they executed.

<figure><img src="https://1659095931-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcnDk3J1AzTgg2NFrGPlh%2Fuploads%2FhvaRsiw75hwcRyG7VuG0%2Fimage.png?alt=media&amp;token=add0c71f-2c8c-41fc-a1aa-b381a9221888" alt="Saga Audit Dialog"><figcaption><p>Saga Audit Dialog</p></figcaption></figure>

The Saga Audit dialog:

* Lists every audit run recorded for the current saga.
* Lets you start new audit scenarios.
* Offers AI assistance that explains error logs and recommends fixes to the saga flow.

You can also view audit results for a single step. This gives you quick access to the step's input data schema and shows how the step behaves with different data.

<figure><img src="https://1659095931-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcnDk3J1AzTgg2NFrGPlh%2Fuploads%2FRTaj0l8vS4AnseaVCekk%2Fimage.png?alt=media&amp;token=a721b269-417c-4d1b-aaa9-a4c819b427ef" alt="Step Audit Dialog"><figcaption><p>Step Audit Dialog</p></figcaption></figure>

## Log Monitoring

Audit runs are mainly for development and testing, so they don't show what happened in requests that weren't audited, including ones that failed. For those cases, Rierino writes detailed logs with a rich, customizable MDC (Mapped Diagnostic Context) that includes request details such as:

* Request ID
* Requester Detail
* API Gateway
* Runner
* Saga ID
* Step ID
* API Path
* Handler
* Action
* State / Domain

Logs also include the error details. At more detailed log levels, you can also trace the event payload at each saga step. Use this only in development, so that sensitive data doesn't end up in your logs.

You can send logs, traces and metrics to your organization's APM and SIEM tools through adapters or OpenTelemetry feeds. For setup details, see [Logs, Traces & Metrics configurations](/installation/administration/logs-and-traces-and-metrics.md).


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rierino.com/quick-start/debugging-with-rierino.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
