> ## 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. # Enable Alerts > Create operational alerts in xorlab and forward them to external systems. Alerting is intended for **operational** monitoring, and can only be used in a limited way to create alerts based on email (security) related data. **Prerequisites** * Complete [Set Up Monitoring](/latest/monitoring-guide) Follow these steps to set up alerting: 1. Open the [Expert Editor](/latest/expert-editor). 2. In the following we will activate alerting for XCC. **Repeat all steps below** in the `monitored_mta` folder instead of `monitoring` to activate MTA alerts. 3. Open the file `/monitoring/alertmanager/alertmanager.yml`. Create it if it does not exist. All alert configuration will be done in this file. 4. Choose the desired alert channel and configure it in `alertmanager.yml`. Here we provide examples for email, webhook and Slack integration. You can find the full list of supported integrations on the official [Prometheus Documentation](https://prometheus.io/docs/alerting/latest/configuration/). This example configuration sends all alerts to a specified email address, see also [prometheus.io - email\_config](https://prometheus.io/docs/alerting/latest/configuration/#email_config). ```yaml theme={null} global: smtp_smarthost: localhost:25 smtp_from: alertmanager@xorlab.example.com smtp_auth_username: # Only required if smtp auth is used smtp_auth_password: # Only required if smtp auth is used smtp_require_tls: true smtp_hello: localhost resolve_timeout: 2m templates: - /config/monitoring/alertmanager/template/email.tmpl # - /config/monitoring/alertmanager/template/custom.tmpl receivers: - name: email email_configs: - to: from: ``` This example configuration sends alerts to different email addresses, based on the severity of the alerts, see also [prometheus.io - email\_config](https://prometheus.io/docs/alerting/latest/configuration/#email_config). There are four levels of alert severities used by the default alerts: normal, medium, high, and critical. ```yaml highlight={2-5,36-37,40-41,44-45,48-49} theme={null} global: smtp_smarthost: smtp_from: smtp_auth_username: # Only required if smtp auth is used smtp_auth_password: # Only required if smtp auth is used smtp_require_tls: true smtp_hello: localhost resolve_timeout: 2m templates: - /config/monitoring/alertmanager/template/email.tmpl # - /config/monitoring/alertmanager/template/custom.tmpl route: receiver: email-normal # default receiver group_by: - alertname group_wait: 1m # initial wait to ensure alerts can be grouped group_interval: 5m # subsequent alerts wait 30m for new alerts if in an active group repeat_interval: 30m # wait for 'repeat_interval' before resending active alerts continue: false # whether an alert should continue matching against subsequent routes routes: - receiver: email-medium matchers: - severity="medium" - receiver: email-high matchers: - severity="high" - receiver: email-critical matchers: - severity="critical" receivers: - name: email-normal email_configs: - to: ', ' from: - name: email-medium email_configs: - to: ', ' from: - name: email-high email_configs: - to: from: - name: email-critical email_configs: - to: from: ``` This example configuration sends all alerts to a specified webhook, see also [prometheus.io - Receiver integration settings](https://prometheus.io/docs/alerting/latest/configuration/#receiver-integration-settings) ```yaml theme={null} route: receiver: webhook group_by: - alertname group_wait: 1m group_interval: 5m repeat_interval: 30m routes: - receiver: webhook receivers: - name: webhook webhook_configs: - url: https://example.com/webhook ``` This example configuration sends all alerts to a specified **Slack** channel, see also [prometheus.io - Receiver integration settings](https://prometheus.io/docs/alerting/latest/configuration/#receiver-integration-settings) and the [Slack documentation](https://api.slack.com/messaging/webhooks). ```yaml theme={null} global: # REPLACE the following slack_api_url with a valid one. slack_api_url: https://hooks.slack.com/services/XXXXXXXXXXX/YYYYYYYYYYY/ZZZZZZZZZZZZZZZZZZZZZZZZ resolve_timeout: 2m receivers: - name: slack-alert slack_configs: channel: text: '{{ template "slack.text.alert" . }}' ``` By default, **Alertmanager** does not send alerts to any real receivers, all alerts are routed to a no-op / blackhole receiver. ```yaml theme={null} route: receiver: blackhole routes: - receiver: blackhole receivers: - name: blackhole ``` 5. Optional: You also find some predefined examples in the same folder. Only the file `alertmanager.yml` will be considered, so they can be safely ignored or deleted if not used. * `alertmanager.email.yml` - Email notification examples, one basic example and one with severity based routing. * `alertmanager.webhook.yml` - Generic webhook example * `alertmanager.slack.yml` - Slack integration example. The different examples can be mixed by configuring different `receivers` and adjusting the `route` configuration accordingly, similar to the *Email receiver (with routing)* example. **Alertmanager** supports more receivers and allows for more advanced configuration (e.g. alerts being sent to more than one receiver, complex routing, etc.), see also [prometheus.io - Route-related settings](https://prometheus.io/docs/alerting/latest/configuration/#route-related-settings). 6. Click **Publish**. The alerting becomes active within about one minute. Have a look at [Test and Troubleshoot Alerts](/latest/monitoring-alerts-testing) to verify them. ## Optional: Enable notifications for resolved alerts If you want to enable notifications about resolved alerts, you have to add the `send_resolved` property and set it to `true` for your selected receiver. 1. Open your active `alertmanager.yml` config file (once for the XCC and once for the MTA). 2. Find the `receivers` group, and under the chosen receiver config add `send_resolved: true`. For example, the receivers config for **email** alerts should look like this: ```yaml highlight={8} theme={null} (...) receivers: - name: email-normal email_configs: - to: alerts@example.com from: alertmanager@xorlab.example.com html: '{{ template "email.default.html" . }}' send_resolved: true (...) ``` 3. Click **Publish**. The monitoring configuration becomes active within about one minute.