Relevant for App Admin / anyone troubleshooting an integration
The Inbound Log is found under Configuration -> Integrations -> Inbound Log. It records every raw signal AlertOps receives from a source system. Any time something is pushed to an Inbound Integration's API URL or sent to its inbound email address, a row is written to the Inbound Log.
This is the first place to look when verifying whether an integration is working. It answers three questions directly: did the signal actually reach AlertOps, what exactly did the source send, and what did AlertOps do with it.
The Inbound Log shows raw signals as they arrived. It is not a record of alerts. A signal can arrive successfully and still not create an alert, depending on the integration's filters and conditions.
Retention: AlertOps stores inbound logs for the last 4 days only. Signals older than that are no longer available in the log, so troubleshooting should be done while the data is still in range.
The Inbound Log List
Relevant for anyone reviewing incoming signals
The list view shows each received signal with the following columns:
| Column | Description |
| ID | The unique message ID for the signal. Click the row to open the full inbound message detail. |
| Date Processed | When AlertOps processed the signal. |
| Source | The source value parsed from the signal, for example CWManageTicket. |
| Source Name | The source system name, for example ConnectWise or Azure. |
| Source Identifier | The unique identifier from the source system, such as a ticket ID. Used for deduplication and for matching close signals to open alerts. |
| Integration | The Inbound Integration that received the signal. |
| Mapping | The mapping status, describing what AlertOps did with the signal. See the reference below. |
| Alert ID | The AlertOps alert created from this signal. Populated only when the signal resulted in a new alert. |
Three filters are available above the list, along with a date range:
- Source / Alert ID search
- All Integrations to narrow to a single integration
- All Mapping Status to narrow to a specific mapping outcome
Viewing an Inbound Message
Click any row to open the Inbound Message detail view. This shows the signal exactly as it was received, along with its processing metadata: Date Sent, Date Received, Date Processed, Status, Integration, Source, Source Name, Source Id, Alert Id, and Subject.
The Body field contains the raw content of the signal.
For API signals, the Body contains the full JSON payload posted by the source system. This is the authoritative view of what the source actually sent, and is the fastest way to confirm whether a field your mapping depends on was present and populated.
For email signals, the Body contains the email body, and the detail view additionally shows the Sender and a Recipient table listing the inbound address the email was delivered to and its type (TO, CC).
Alert ID and Viewing the Alert
Relevant for anyone tracing a signal to an alert
The Alert ID column is populated only when the signal initially resulted in MappedOpened, meaning all conditions in the integration matched correctly and a new alert was created. When an Alert ID is present, that alert thread can be opened in the Alerts section for the full notification and escalation history.
Signals that were appended, ignored, or otherwise did not open a new alert will not show an Alert ID on their own row.
Mapping Status Reference
Relevant for anyone interpreting the Mapping column
The mapping status explains what AlertOps did with the signal after parsing it. These are the values available in the All Mapping Status filter: (note - a majority of the mapping statuses are based on how the mapping is done under 'Rules for Opening and Closing Alert' under Advanced Settings of the Inbound Integration)
| Mapping Status | Meaning |
| MappedOpened | The signal matched all conditions in the integration and a new alert was created. An Alert ID is populated, and the alert can be viewed in the Alerts section. This is the expected status for a working open path. |
| MappedAppended | A signal arrived with the same Source, Source Name, and Source Identifier as an existing alert that was still open, so the content was appended to that alert instead of opening a new one. This is deduplication, and it does not send a new notification. |
| MappedFailed | AlertOps could not map the signal. This most commonly happens when the Filters configured in the Inbound Integration do not match the incoming payload. Check the filter values against the raw body in the inbound message. |
| Mapped | The signal was mapped successfully against the integration without falling into one of the more specific outcomes below. |
| MappedAssigned | The signal drove an assignment on the matching alert, based on assignment details in the payload. The 'Assignee' field matched accurately from the payload |
| MappedClosed | The signal matched the integration's close conditions (close alert when) and closed the existing open alert. |
| MappedUpdated | The signal matched the integration's 'update alert when' conditions and closed the existing open alert. |
| MappedMerged | The signal was mapped to an alert that was merged into another alert. Merge definitions are usually defined in a correlation profile under AIOps |
| MappedGrouped | The signal was mapped and grouped with related alerts based on the same source |
| MappedIgnored | The signal was mapped but intentionally not acted on, so no alert was opened, updated, or closed. |
| MappedIgnoredCloseWithNoOpen | A close signal arrived but there was no corresponding open alert to close. Common when the source system sends a close for something AlertOps never opened, for example because the open signal was filtered out. |
| MappedIgnoredOpenDuplicates | A duplicate open signal arrived for an alert that was already open, and was ignored rather than appended. |
| MappedIgnoredStatusMismatch | The status value in the payload did not match the status the integration expected for the action, so no action was taken. |
| Maintenance | The signal arrived while an applicable Maintenance Window was active, so no alert or notification was generated. |
Troubleshooting Tips
- No row in the Inbound Log at all. The signal never reached AlertOps. Verify the API URL or inbound email address, the authentication, and whether the source system actually fired. Also check timezones of the account/user/system and filter accordingly.
- Row present but no Alert ID. The signal arrived and was parsed, but did not open an alert. Read the mapping status to see why, then compare the raw body against the integration's filters and conditions.
- MappedFailed. Start with the Filters section of the Inbound Integration. Compare each filter field and value against the raw payload in the inbound message body.
- Expected a notification but got MappedAppended. This is deduplication working as designed. The source sent a signal matching an already open alert, and appended signals do not notify.
- Investigate within 4 days. Because logs are retained for 4 days, capture or export the raw body while troubleshooting rather than relying on the log later.