> ## Documentation Index > Fetch the complete documentation index at: https://docs.llmgrid.ai/llms.txt > Use this file to discover all available pages before exploring further. # Logging & Alerts > Configure logging integrations, Slack alerts, operational alert thresholds, and email notifications. ## Overview The **Logging & Alerts** section provides centralized management for platform logging, operational alerts, and email notifications. Use this section to: * Send request and execution data to external logging and observability platforms * Receive operational alerts through Slack * Configure alert thresholds and reporting intervals * Receive email notifications for selected platform events The page is organized into four tabs: * **Logging Callbacks** * **Alerting Types** * **Alerting Settings** * **Email Alerts** *** ## Logging Callbacks The **Logging Callbacks** tab allows administrators to send platform activity and telemetry to supported external logging and observability systems. ### Add a Logging Callback Select **Add Callback** to configure a new integration. 1. Select the required **Callback** from the dropdown. 2. Enter the authentication and configuration information required by the selected integration. 3. Save the callback. 4. Verify that the callback appears under **Active Logging Callbacks**. Configuration fields change based on the selected callback. Examples of integrations available in the UI include observability platforms, tracing systems, analytics services, and custom callback APIs. > Credentials and connection information should be managed securely and limited to the permissions required by the integration. *** ## Alerting Types The **Alerting Types** tab controls which operational conditions generate Slack alerts. ### Slack Webhook Requirement Operational alerts currently support **Slack Incoming Webhook URLs**. Before enabling an alert, create an incoming webhook for the Slack workspace and channel that should receive notifications. See the [Slack Incoming Webhooks documentation](https://docs.slack.dev/messaging/sending-messages-using-incoming-webhooks/) for setup instructions. Each alert type can have its own Slack Webhook URL, allowing different operational events to be routed to different Slack channels. *** ### LLM Exceptions Enable **LLM Exceptions** to receive notifications when model requests encounter exceptions. This alert is useful for detecting: * Model invocation failures * Provider errors * Unexpected inference errors * Production request failures *** ### LLM Responses Too Slow Enable **LLM Responses Too Slow** to receive notifications when model responses exceed the configured performance expectations. Use this alert to monitor: * Provider latency * Model performance degradation * Unexpected response-time increases *** ### LLM Requests Hanging Enable **LLM Requests Hanging** to detect requests that remain unresolved for an unexpectedly long period. This alert can help identify: * Provider connectivity problems * Long-running requests * Timeout-related conditions * Stalled model calls *** ### Budget Alerts Enable **Budget Alerts (API Keys, Users)** to receive notifications related to configured budget conditions. Use this alert with LLMGrid budget controls to monitor usage across users and API keys. *** ### Database Exceptions Enable **Database Exceptions (Read/Write)** to receive alerts when database read or write operations encounter errors. This can provide early visibility into backend persistence or connectivity issues. *** ### Weekly/Monthly Spend Reports Enable **Weekly/Monthly Spend Reports** to send recurring usage and spend reports through the configured Slack destination. This is useful for: * Platform administrators * FinOps teams * AI platform owners * Usage governance reviews *** ### Outage Alerts Enable **Outage Alerts** to receive notifications when error activity indicates a potential model outage. Outage sensitivity is controlled through the settings available under **Alerting Settings**. *** ### Region Outage Alerts Enable **Region Outage Alerts** to monitor provider-region availability. This can help identify incidents affecting multiple models within the same provider region. *** ## Configure Slack Alerts For each alert type: 1. Enable the alert using its toggle. 2. Enter the required **Slack Webhook URL**. 3. Repeat for any additional alerts you want to enable. 4. Select **Save Changes**. ### Test Alerts Select **Test Alerts** after configuration to verify that alerts can successfully reach the configured Slack destination. > Testing alerts before relying on them for production monitoring is strongly recommended. *** ## Alerting Settings The **Alerting Settings** tab controls global operational alert behavior, reporting intervals, and outage detection thresholds. *** ### `slack_alerting` Enables or disables Slack alerting for operational monitoring. Slack alerts can cover conditions such as: * Model outages * Budget events * Spend tracking failures *** ### `daily_report_frequency` Controls how frequently deployment latency and failure reports are generated. The value is specified in **seconds**. *** ### `report_check_interval` Controls how frequently the background process checks whether a report should be sent. The value is specified in **seconds**. A shorter interval checks for pending reports more frequently. *** ### `budget_alert_ttl` Defines how long a budget alert remains cached. The value is specified in **seconds**. This helps prevent the same budget condition from generating repeated notifications within a short period. *** ### `outage_alert_ttl` Defines the error observation window used for model outage alerts. The value is specified in **seconds**. Errors occurring within this window contribute to outage detection. *** ### `region_outage_alert_ttl` Defines the error observation window used for provider-region outage alerts. The value is specified in **seconds**. Region outage alerts can identify failures affecting multiple models operating in the same region. *** ### `minor_outage_alert_threshold` Defines the number of qualifying errors required for a condition to be treated as a **minor outage**. The UI notes that `400` errors are not counted toward this threshold. *** ### `major_outage_alert_threshold` Defines the number of qualifying errors required for a condition to be treated as a **major outage**. The UI notes that `400` errors are not counted toward this threshold. *** ### `max_outage_alert_list_size` Controls the maximum number of errors retained for a model or region during outage evaluation. This setting limits the size of the cached error list used for outage detection. *** ### Update Alerting Settings After modifying values, select **Update Settings** to apply the changes. Settings marked **In Config** indicate values currently defined through platform configuration. *** ## Email Alerts The **Email Alerts** tab provides email notifications for selected administrative events. Email alerting has two parts: 1. **Email Notifications** 2. **Email Server Settings** *** ## Email Notifications Select the events that should trigger an email notification. The UI currently provides notifications for: ### `key_created` Sends an email notification when a new Virtual Key is created. *** ### `key_rotated` Sends an email notification when a Virtual Key is rotated. *** ### `invitation_created` Sends an email notification when a new user invitation is created. This is particularly useful for tenant administrators managing user onboarding. *** ### Save Notification Preferences Select **Save Changes** after enabling or disabling notification events. Select **Reset to Defaults** to restore the default email notification configuration. *** ## Email Server Settings Email notifications require an SMTP server. Configure the following fields: ### `SMTP_HOST` Hostname of the SMTP server. Example: [smtp.example.com](https://smtp.example.com) ### `SMTP_PORT` Port used by the SMTP server. The appropriate port depends on the SMTP service and its security configuration. ### `SMTP_USERNAME` Username used to authenticate with the SMTP server. ### `SMTP_PASSWORD` Password or credential used for SMTP authentication. > Treat the SMTP password as a sensitive credential. ### `SMTP_SENDER_EMAIL` Email address shown as the sender of LLMGrid notifications. **Example** [notifications@example.com](mailto:notifications@example.com) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.