> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes.
> xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal.
> Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can.
> Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames.
> Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing.

# Test and Troubleshoot Alerts

> Fire a synthetic alert to prove the delivery path works, and diagnose it when nothing arrives.

## Trigger a test alert

To trigger a test alert, and verify that the routing and configuration is correct, SSH to the host and execute the following command:

<Tabs>
  <Tab title="XCC">
    ```shell theme={null}
    docker exec -it monitoring_config trigger_an_alert "Summary" "Description" "Severity"
    ```
  </Tab>

  <Tab title="MTA">
    ```shell theme={null}
    docker exec -it monitored_mta_config trigger_an_alert "Summary" "Description" "Severity"
    ```
  </Tab>
</Tabs>

Be patient, as it takes some time for the **Alertmanager** to send the alert. To find out how long you should wait, check the value of `route.group_wait` (or the same value under the specific severity you have used) in the `/monitoring/alertmanager/alertmanager.yml` file opened in the [Expert Editor](/latest/expert-editor) (the default value is one minute).

## Troubleshoot alerts

When something is not working as expected, you can check the logs of **Prometheus** (which creates the Alerts) and **Alertmanager** (which sends the alerts to the external systems \[receivers]) to see if there are any errors:

<Tabs>
  <Tab title="XCC">
    Prometheus logs:

    ```shell theme={null}
    docker logs monitoring_prometheus
    ```

    Alertmanager logs:

    ```shell theme={null}
    docker logs monitoring_alertmanager
    ```
  </Tab>

  <Tab title="MTA">
    Prometheus logs:

    ```shell theme={null}
    docker logs monitored_mta_prometheus
    ```

    Alertmanager logs:

    ```shell theme={null}
    docker logs monitored_mta_alertmanager
    ```
  </Tab>
</Tabs>

If those logs are not enough, you can use the `log.level` setting to enable further debug logs of **Prometheus**. Go to the `/monitoring/prometheus/prometheus.properties` (for XCC monitoring) or `/monitored_mta/prometheus/prometheus.properties` (for MTA monitoring) and uncomment the following line:

```yaml theme={null}
#log.level=debug
```

You can also use this setting to only log messages with these severities (or above):

* `info`
* `warn`
* `error`

You can check if monitoring is running properly by executing the following command and confirming that the status of the containers is `healthy`:

```shell theme={null}
docker ps --filter "name=monitor*"
```