> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rwsintegration.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Monitoring & Debug
> Follow your integration runs in the app and troubleshoot them using Slack log channels
## Overview
To verify that your integration is running correctly or to diagnose failures in **Extract**, **Transform**, or **Load**, use the Slack log channels created for your tenant. RWS Integration posts run logs as **json files** in these channels.
## Integration status page
In workspaces where it's enabled, opening an integration shows a status page instead of the editable form. It gives you a quick health check without leaving the app:
* The **current or last execution** and its outcome
* How long each phase took: **Extract**, **Transform**, and **Load**
* How many records each phase handled
From this page you can also:
* Click **Run now** to start a run immediately. The page is read-only, so there is nothing to save. After you confirm in the dialog, the run starts right away.
* Click **Edit Integration** to open the editable form.
The status page is enabled per workspace. If you don't see it, your workspace still opens the editable form; talk to the RWS team if you'd like it enabled.
## Slack channels
In Slack, you will see four channels for your tenant:
`{{ tenant }}`-extract-success
Logs for **successful extracts** for all integrations
`{{ tenant }}`-extract-error
Logs for **failed extracts** for all integrations
`{{ tenant }}`-transform-error
Logs for **transform errors** for all integrations
`{{ tenant }}`-load-error
Logs for **load errors** for all integrations
## Understanding the logs
Each log file contains structured JSON data that helps you diagnose issues. Below are examples of common success and error scenarios and how to interpret them.
### Extract Success
When an extraction is successful, you'll see a log like this:
```json theme={null}
{
"type": "Error",
"category": "Integration Extract - Success",
"timestamp": "2025-12-09T23:39:05.458Z",
"message": "Extract Success",
"data": {
"merchant": "tenant",
"integrationName": "integration",
"integrationId": "682693a60de87c17bbea7d85",
"hasDatapoints": true,
"total": 69376,
"iterations": 1,
"fail": 0,
"success": 1
}
}
```
#### Key fields for Extract success:
| Field | Description |
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `data.hasDatapoints` | Whether the integration was able to extract any datapoints |
| `data.total` | Number of datapoints extracted |
| `data.iterations` | Number of extraction attempts performed. This is always the **sum of `data.fail` and `data.success`** for the run. It also reflects the number of parallelization parameters used; for example, if parallelization is set as `123,456` (2 parameters), then `iterations` will be 2 for that integration. |
| `data.fail` | Number of failed extraction attempts |
| `data.success` | Number of successful extraction attempts |
### Extract Error
When an extraction fails, you'll see a log like this:
```json theme={null}
{
"type": "Error",
"category": "Integration Extract - Failed",
"timestamp": "2025-12-10T23:34:49.768Z",
"message": "Extract Error",
"data": {
"merchant": "tenant",
"integrationName": "integration",
"integrationId": "682693a60de87c17bbea7d81",
"total": 0,
"iterations": 1,
"fail": 1,
"success": 0,
"errors": [
"HTTP status error @ ApiPage.extract(): status=500 response=\"Internal Server Error\""
]
}
}
```
#### Key fields for Extract errors:
| Field | Description |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `data.total` | Number of datapoints extracted |
| `data.iterations` | Number of extraction attempts performed. This is always the **sum of `data.fail` and `data.success`** for the run. It also reflects the number of parallelization parameters used; for example, if parallelization is set as `123,456` (2 parameters), then `iterations` will be 2 for that integration. |
| `data.fail` | Number of failed extraction attempts |
| `data.success` | Number of successful extraction attempts |
| `data.errors` | Error messages returned/raised during extract (often includes HTTP status + response) |
Extract errors often include HTTP status codes and response messages, which can help you identify API connectivity issues or endpoint problems.
### Transform Error
When a transformation fails, you'll see a log like this:
```json theme={null}
{
"type": "Error",
"category": "Datapoint Transform",
"timestamp": "2025-11-22T09:51:24.400Z",
"message": "There was an error in transform-record operation",
"data": {
"merchant": "tenant",
"integrationName": "integration",
"integrationId": "6733572df58838c37514d907",
"total": 1,
"success": 0,
"failed": 1,
"errors": [
"Error while executing the business rule example-doc with id 67570b4a1891fa735a486ae2: Cannot read property of undefined/null. Data is: {{ datapoint }}"
]
}
}
```
#### Key fields for Transform errors:
| Field | Description |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `data.total` | Number of datapoints processed by transform |
| `data.failed` | Number of datapoints that failed transformation |
| `data.success` | Number of datapoints transformed successfully |
| `data.errors` | Transformation error details (points to the rule that failed), also includes the datapoint that caused the error that can be identified by `Data is: {{ datapoint }}` |
Simple transformations doesn't cause transform errors logs, make sure that mapping is correct and matches exactly the names of the fields in the source
Transform errors point to specific business rules that are causing issues. Check the error message for the exact rule ID.
### Load Error
When a load operation fails, you'll see a log like this:
```json theme={null}
{
"type": "Error",
"category": "Datapoint Load",
"timestamp": "2025-12-10T17:03:30.527Z",
"message": "There was an error processing requests",
"data": {
"merchant": "tenant",
"integrationName": "integration",
"integrationId": "6733572df58838c37514d902",
"failed": 1,
"errors": [
"HTTP status error @ LoadService.load(): status=404 response={\"error\":{\"code\":\"OMS007\",\"message\":\"Register Not Found\",\"exception\":null}}"
],
"requests": [
"{{ request }}"
]
}
}
```
#### Key fields for Load errors:
| Field | Description |
| --------------- | --------------------------------------------------------------------------- |
| `data.failed` | Number of failed load requests |
| `data.errors` | The response/error returned by the destination API during load |
| `data.requests` | The request payload sent to the destination API (useful to reproduce/debug) |
## Search logs for a specific integration
To find logs for a specific integration run across channels:
1. **Copy the integration ID:**\
Copy the `integrationId` from the integration UI in your dashboard.
2. **Search in Slack:**\
Paste the ID into the Slack search bar.
3. **Filter to files:**\
Filter the search to **Files** to see only JSON log files.
4. **Review the logs:**\
Open the matching file(s) to view the full JSON log for that integration run.
You can search across all four channels simultaneously by using the integration ID, making it easy to trace an entire integration run from extract through load.