# Logs for data exchange
Logs show how data is processed (whether synchronously or asynchronously) and delivered via Redox.
## What are logs?
A **log** is a step-by-step record of what data was exchanged, as well as how and when it was sent. This record is an aggregation of small transactional components with the request details and data payloads exchanged between you and your connection.
Logs are an essential tool for monitoring or debugging since they contain the what, when, and how of your data exchange. By using logs, you can:
- Confirm success: See when a message was successfully sent or received.
- Inspect payloads: View the exact payload data that was sent or received to verify its contents.
- Diagnose errors: Pinpoint where a failure occurred and view related error messages.
> **Missing our old terminology?**
>
> Previously, we used the terms _message_ and _transmission_. For posterity’s sake, here are the those definitions:
>
> - A message was the request sent by the source system to Redox.
> - A transmission was the request received by the destination system via Redox.
>
> Logs replace the concepts of messages and transmissions by combining them. Each log is a unique combination of a message and a transmission. Resubmitted transmissions are analogous to log attempts.
## When are logs created?
Redox creates a log for every attempted request. A couple of caveats:
- If a notification is automatically retried multiple times, one log is created with multiple attempt IDs.
- If one notification is sent to multiple destinations, a log is created for each destination the notification was sent to.
## Where to view logs
You can review log information on the Logs page of the Redox dashboard. [Learn how to search for logs](/how-to-use-redox/search-for-logs).
*The Logs page in the Redox dashboard*
Redox sorts logs by timestamp with the most recent one at the top. Just note that if you’re new to Redox, there won’t be any logs to display until your organization starts using any of the developer tools to send test messages.
> **Role permissions for log data**
>
> Logs include payloads, so protected health information (PHI) may be visible in the dashboard, depending on a user’s role assignment.
>
> All users can view and search log metadata. However, if a user assigned to an observer role selects a log, the related payloads aren’t visible. Only users assigned to an engineer or a support role may view and search log payloads.
>
> [Learn about roles](/basics/managing-access-for-your-redox-organization/what-are-user-roles).
You can also retrieve log data via API with these Platform API endpoints:
- [Get log by id](https://docs.redoxengine.com/permalink/51b1bce8-37f9-5367-8bf9-427e42e2f5ac-get-log-by-id)
- [Search metadata](https://docs.redoxengine.com/permalink/308acd28-f5b7-56ad-a79e-a25e0d098f35-search-metadata)
- [Search payloads](https://docs.redoxengine.com/permalink/38152340-b2fb-54af-9df6-5d6628a95c7a-search-payloads)
- [Run log inspector](https://docs.redoxengine.com/permalink/f44fa42d-4ecf-529b-90c8-30a8e145c779-run-log-inspector)
> **Log payloads not returned**
>
> You can search log metadata or payloads via API, but you won’t receive log payloads in the responses. You can only review log payload contents in the Redox dashboard (if you’re assigned to an engineer or support role).
## AI Assistant Suite for logs
We offer two AI assistants to help you understand your logs:
**Log Summary Assistant** gives you an overview of the log’s purpose, processing flow, customizations, and outcomes. Click the **Summarize** button on a log try it out.
*Log Summary Assistant in the Logs UI*
*Example of a log summary *
**Payload Summary Assistant** breaks down a complicated payload into its business and data context. You must have access to view payloads to use Payload Summary Assistant (i.e., users assigned to an **engineer** or a **support** role). Click the **Summarize** button on a payload try it out.
*Payload Summary Assistant in the log details*
*Example of a payload summary*
AI assistants are only available if your organization owner opts in to use them. [Learn how to enable AI assistants](/how-to-use-redox/enable-redox-ai-assistants-or-mcp-server).
## How to read logs
When you open a log, you’re seeing the story of a single transaction. Generally, here’s how to read a log:
1. Check the status: The first thing to look at is the overall log status (see log statuses). This gives you an immediate idea of the outcome.
2. Review the details: The log details tell you who sent the data (i.e., source), who it was for (i.e., destination), and which data model was used.
3. Trace the processing stages: The log stages show the journey of your data through Redox. This includes any data operations that were applied (e.g., filter, translation, config modifier).
4. Inspect the payload: Use log inspector to view the actual data that was transmitted. This is critical for debugging issues with data format or content.
Let’s break down the log more specifically:
*How to read a log*
| | **Log detail** | **Description** |
| --- | --- | --- |
| 1 | Data model | The Redox data model, FHIR resource, or FHIR notification that data was converted to in order to facilitate data exchange. Review our available schemas: [Data models](https://docs.redoxengine.com/permalink/data-model-landing-page) [FHIR resources](https://docs.redoxengine.com/permalink/fhir-resources-landing-page) [FHIR notifications](https://docs.redoxengine.com/permalink/fhir-notification-landing-page) |
| 2 | Timestamp | The date and time that the log finished processing (i.e., reached a final state). Review log statuses below for definitions. |
| 3 | Log type | The type of log, which indicates which system originated the message and whether the exchange was asynchronous or synchronous. `SEND`: A source in your organization initiated the asynchronous notification to your connection. `RECEIVE`: A destination in your organization received the asynchronous notification from your connection. `REQUEST`: Your system initiated the synchronous query from a source in your organization. `RESPOND`: Your system responded to the synchronous query from a destination in your organization. Learn about [handling notifications](/basics/data-exchange-with-redox/handling-notifications-and-responses) and [handling queries](/basics/data-exchange-with-redox/responding-to-queries). |
| 4 | Log status | The current or final state of the log. Review log statuses below for definitions. |
### Log statuses
Every log has a distinct status that reflects its current or final state:
| Status | Description |
| --- | --- |
| `SUCCEEDED` | The request was successfully processed and delivered to the designated destination. |
| `FAILED` | The request didn’t process correctly or couldn’t be delivered to the designated destination. In the case of a failed asynchronous notification to a production environment, this status could mean that retries are in progress or have been attempted but weren’t successful. Redox doesn’t automatically send notifications if a log fails. However, you can [set up traffic alert rules](/how-to-use-redox/create-alert-rules-and-links) to notify you when there are a certain number of failed logs. |
| `FILTERED` | Redox filtered the data payload based on your filter settings for the related data model or FHIR notification. [Read about filters](/how-to-use-redox/define-and-manage-filters). |
| `PENDING` | This is an interim state that means the request is queued for or currently processing. This status will result in one of the final states listed above. |
> **Log type: Unknown**
>
> The log type may be `UNKNOWN` if an error occurs during initial processing. If so, log details like subscription, data model, or event type may not be available either.
### Processing stages and operations
In the Redox dashboard, we provide a visual of how a log is processed in five- or nine-block stages, which represent high-level events of log processing. The number of blocks depends on the log type.
For **async** traffic, the log details show these five **stages**:
1. Source
2. Pre-processing
3. Redox
4. Post-processing
5. Destination
*Asynchronous logs visualized in 5 stages*
For **sync** traffic, the log details show these nine **stages**:
1. Source
2. Pre-processing (outbound)
3. Redox
4. Post-processing (outbound)
5. Destination
6. Pre-processing (inbound)
7. Redox
8. Post-processing (inbound)
9. Source
*Synchronous logs visualized in 9 stages*
Log stages give you an idea of how data passes from a source, through Redox, to a destination (and potentially back again). However, a more detailed view of log processing is conveyed through operations.
**Operations** are individual steps in log processing, where a payload is altered in some way (e.g., cleansed, tagged, translated, filtered). [Learn about operations](/basics/data-exchange-with-redox/operations-for-data-processing).
To summarize, operations are the way work gets done, while stages are how we bucket the work. Most importantly, stages show high-level events and don’t have a strong ordering of step-by-step events like operations.
### Log details
Selecting a processing stage opens the log details, which includes any available:
- **Metadata**: A stage’s metadata could include timestamps, communication method, or source / destination names for that particular processing stage.
- **Request, response,** or **data model payloads**: A **payload** is a captured copy of the log at a specific point during processing. It’s often a JSON object. To view any payloads, users must have a support or engineer role in the environment. [Learn about roles](/basics/managing-access-for-your-redox-organization/what-are-user-roles).
- **Data operation(s)**: Any details about customer-managed operations, including filters, config modifiers, or translation sets. Data operation details are visible to any users in the environment. To edit a related operation, a user must have a support or engineer role.
*Log details*
### Operation details
If a log processing stage has operations you manage linked to it (i.e., filters, translations, config modifiers, or processors), there are icons for them. If an icon is grayed out, it means it didn’t take effect in this processing stage.
*Operation icons*
*Filter and translation icons*
Selecting the processing stage allows you to see which customer-managed operations were applied to the log.
Translation details
> **Not Redox base configs**
>
> Operation details don’t include data about Redox base configs (including Redox base translations inside configs). Any translations you see here are only for the translations you create yourself. [Learn more about translation sets](/how-to-use-redox/create-translation-sets-and-links).
The log details show an outcome for translations, which indicates what happened to each defined field path:
*Successful translation*
*Unsuccessful translations*
| **Outcome** | **Definition** |
| --- | --- |
| `Translated` | We found the value at the specified field path and translated it based on the related value set mapping. |
| `Value not found` | We found a value at the specified path, but it wasn’t the value we expected from the related value set mapping. So we didn’t translate it. |
| `Field not found` | We didn’t find the field path you specified in the translation set. |
Filter details
For Block all rules, the filter details show that the message was blocked due to the defined filter rule.
*"Block all" outcome*
For Send if rules, the log details show an outcome for each rule.
If you have multiple Send if rules, the rules are evaluated in the order they’re defined. If a filter rule isn’t met, any subsequent rules aren’t evaluated.
*"Send if" outcomes*
| **Outcome** | **Notes** |
| --- | --- |
| Satisfied | The criteria for this filter rule was met. The next filter rule was evaluated. |
| Unsatisfied | The criteria for the filter rule wasn’t met. Any subsequent filter rules weren’t evaluated. |
| Skipped | A previous filter rule was unsatisfied, so this rule wasn’t checked at all. |
Config modifier details
The config modifier details show the outcome for any config modifier(s) at a particular processing stage.
*Config modifier details*
Click the Config modifiers tab to open a table with any linked config modifiers. The table shows the status, name, owner, processing location, and flavor of each config modifier. For any `PUT` flavor config modifiers managed by your organization, you can click the table row to expand more details with the schema and output.
Potential statuses include:
| **Outcome** | **Definition** |
| --- | --- |
| `Succeeded` | We found the selector path and executed the instructions defined by the config modifier. The icon on the processing stage is bolded to show it applied successfully. |
| `Field not found` | We didn’t find the selector path specified in the config modifier. The icon on the processing stage is grayed out to show it wasn’t applied. |
| `Failed` | A `PUT` config modifier didn’t execute for some reason. This only occurs on very rare occasions, so you shouldn’t expect to see this status. |
[Learn more about config modifiers](/how-to-use-redox/change-data-with-config-modifiers).
Processor details
> **Open beta feature**
>
> This is an open beta feature, which means you won’t see it available in your organization until you opt in. If you’re interested in joining this beta, [talk to a Redoxer](https://redoxengine.com/forms/contact-us/) to find out if you’d be a good fit.
The processor details show the outcome for any processor(s) at a particular processing stage.
Click the Processors tab to open workflow viewer, an interactive visual of how a processor ran. [Learn more about workflow viewer](/how-to-use-redox/use-workflow-viewer-to-visualize-processors).
Or, [learn more about processors](/basics/data-exchange-with-redox/orchestrate-your-unique-data-workflows).
## What is log inspector?
While log details show high-level processing, they’re limited to showing only what was delivered and when. Not every message delivers smoothly, though, and you might want to dig into the details of unexpected errors or unsuccessful deliveries / receipts.
**Log inspector** shows you operation details grouped by processing stage ([read about operations](/basics/data-exchange-with-redox/operations-for-data-processing)). Not every log stage appears in log inspector, though; only stages where operations executed appear. This empowers you to do your own troubleshooting to find where or what might have gone wrong during log processing.
*Log inspector*
A user assigned to a support or engineer role can run the log inspector either in the Redox dashboard or with the Platform API. Running log inspector shows the processing snapshots at the input and output points of the operation and the result of each step. Most importantly, you can see whether the operation did nothing, succeeded, or failed.
Redox captures operations for all logs, not just the ones that you run log inspector on. However, extended payload snapshot data isn’t captured for logs outside of log inspector. Those extra details only result from running the log inspector.
[Learn how to use log inspector](/how-to-use-redox/run-log-inspector).