> For the complete documentation index, see [llms.txt](https://docs.contextual.io/documentation-and-resources/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.contextual.io/documentation-and-resources/components-and-data/flows/node-reference/common/log-tap.md).

# Log Tap

Use a Log Tap node in your Flow to send log messages to the Flow Editor [Debug](/documentation-and-resources/components-and-data/flows/node-red-flow-editor/in-flow-testing-with-debugger.md) sidebar, and to [Agent Logs](/documentation-and-resources/components-and-data/agents/agent-details/logs.md), with varying levels of detail based on your development needs and operational preferences. Tenant log retention is configured as 1, 7, or 30 days. The 1-day tier is the provisioning fallback/default.

#### Basic Node Usage Example

```mermaid
flowchart LR
    A["Event Start"] --> B("Code Step 1")
    B --> C("Log Tap 1")
    C --> D("Code Step 2")
    D --> E("Log Tap 2")
    E --> F["Event End"]
    style A fill:#FFFFFF,stroke:#000000
    style B fill:#FFFFFF,stroke:#000000
    style C stroke:#00C853,color:#FFFFFF,fill:#00C853
    style D fill:#FFFFFF,stroke:#000000
    style E fill:#00C853,stroke:#00C853,color:#FFFFFF
    style F fill:#FFFFFF,stroke:#000000
```

By adding a Log Tap node in between key operations in your Flow, log messages will be written containing important information about the status of operation of the Flow, at that point, based on the configuration of the Log Tap node itself.

#### Configuring a Log Tap Node

To configure a Log Tap node in the [Flow Editor](/documentation-and-resources/components-and-data/flows/node-red-flow-editor.md), drag it from the Palette to the Workspace canvas, then double-click the node to open and configure its behavior.

<figure><img src="https://2803907488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJF7AoTYz7NHacejws5p9%2Fuploads%2Fgit-blob-2df3ff05af46db20fb8f9cd049bcccf076e3030e%2Fimage.png?alt=media" alt="Example of settings for a Log Tap node"><figcaption><p>Example of settings for a Log Tap node</p></figcaption></figure>

1. Provide an optional **Name** for the node.
   * By default a Log Tap node will be shown with a label of "log tap", but the value you provide in the Name field will replace it in the Flow Editor UI making your flow easier to read and understand.
   * This value will also be included in the Flow Editor [Debug Panel](/documentation-and-resources/components-and-data/flows/node-red-flow-editor/in-flow-testing-with-debugger.md), as well as in [Agent Logging](/documentation-and-resources/components-and-data/agents/agent-details/logs.md), to help find and understand log messages.
2. Choose the desired detail of logging for **Output**.
   * *msg.* - <mark style="background-color:red;">note</mark>
   * *complete message object* - <mark style="background-color:red;">note</mark>
   * *expression* - <mark style="background-color:red;">note</mark>
3. Choose the desired level for the log message, using **Log Level**. When the flow runs in an Agent, a Log Tap message is written to Contextual's execution logs only when its configured Log Level meets or exceeds the Agent's current log level. For example, an Agent set to **Warn** writes warn and error messages, but not info or debug. Agent log levels can be changed at any time without restarting the Agent.
   * *debug* - typically used for logging messages with a high level level of detail, useful during software development and debugging. Debug logs are typically not enabled in a production environment unless troubleshooting a specific issue due to the high volume of log output that can be generated.
   * *info* - typically used for informational messages that highlight the progress of an application at a coarse-grain level. Info logs are typically enabled in a production environment to provide a general sense of application activity without being too verbose.
   * *warn* - typically used to indicate there is a potential issue or a situation that could lead to a problem in the future, but the application is running as expected. Warn logs are typically always enabled.
   * *error* - typically used to log error events that might still allow the application to continue running. Error logging usually captures events that are not fatal but significant. Error logs are always enabled.
4. Select **Send to Console** to also write the log message to the Agent's container console output. This option is not required for [Agent Logs](/documentation-and-resources/components-and-data/agents/agent-details/logs.md): when a flow runs in an Agent, every Log Tap message that passes the Log Level check above is written to Agent Logs whether or not this option is selected.
   * Console output is collected by Contextual's internal platform monitoring and is not viewable in the Contextual Console. Leave this option cleared unless Contextual support asks you to enable it, for example to monitor or alert on a specific Log Tap.
   * Selecting this option sends a second copy of every message, which adds log volume. Avoid it for Log Taps that output large payloads, such as the complete message object or base64-encoded files.
5. Select **Send to Sidebar** to display the log message in the Flow Editor Debug sidebar, which is specifically useful for [in-flow testing with the debugger](/documentation-and-resources/components-and-data/flows/node-red-flow-editor/in-flow-testing-with-debugger.md), allowing you to quickly test and observe many aspects of your flow development, without requiring an Agent restart for quick testing and validation.


---

# 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.contextual.io/documentation-and-resources/components-and-data/flows/node-reference/common/log-tap.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.
