> ## Documentation Index > Fetch the complete documentation index at: https://docs.incident.io/llms.txt > Use this file to discover all available pages before exploring further. # Alert sources > Ingest alerts from external tools, regardless of format or platform. Alert sources connect external monitoring tools to incident.io, bringing issues detected across your systems into your on-call workflow. Once configured, alert sources form the entry point for routing to on-call teams, triggering escalations, and creating incidents. **To add and configure an alert source:** 1. Using the sidebar, navigate to **Settings → Alerts** 2. Click the **+** button to add alert sources 3. Select your alert source, choosing from [native integrations](#native-integrations), [HTTP sources](#default-http-sources), or [email sources](#email-sources) and click **Continue** 4. Follow the in-dashboard instructions to connect, send test alerts, and complete setup incident.io also supports [live phone call routing](/on-call/live-call-routing) for voice-based alerts. ## Native integrations Connect observability platforms, cloud providers, error tracking tools, uptime monitors, ticketing platforms and more, with pre-configured integrations. Receive alerts when metrics breach thresholds, applications throw errors, services go down, or security threats are detected. ## Default HTTP sources HTTP sources enable receiving alerts from any tool not covered by the [native integrations list](#native-integrations). Use default HTTP sources when you control the webhook payload from external tools. incident.io provides a URL endpoint where you send alerts with a custom payload structure. ```json Expected body structure theme={null} { "title": "My first alert", "description": "Some additional context", "deduplication_key": "first-alert", "status": "firing", "metadata": { "team": "core", "service": "api" } } ``` Use the `metadata` field to set [alert attributes](/on-call/alert-attributes) for routing and filtering. See the [Alert Events API documentation](https://docs.incident.io/api-reference/alert-events-v2/) for full field specifications and validation rules. ## Custom HTTP sources Use custom HTTP sources when working with tools that send webhooks with HTTP payload structures that cannot be modified. Write custom JavaScript within these sources to transform those payloads into incident.io's expected alert format. ```json Example payload from external tool theme={null} { "title": "High CPU usage on server-01", "status": "firing", "description": "CPU usage exceeded 90% threshold", "url": "https://monitoring.example.com/alerts/12345", "team": "platform", "severity": "critical" } ``` ```javascript Your transform expression theme={null} // $ represents your incoming payload return { title: $.title ? $.title : 'Custom HTTP alert', status: $.status === 'resolved' ? 'resolved' : 'firing', description: $.description ? $.description : '', source_url: $.url, metadata: { team: $.team, severity: $.severity }, }; ``` ## Email sources Send emails to a unique email address to create alerts in incident.io automatically. Use email sources for monitoring tools or scripts that only send email, or for customer support and internal escalations where critical emails should trigger alerts. Each email creates a new alert. For full setup details — including how to use a transform expression to deduplicate alerts and derive status from email content — see [Email alert sources](/alerts/email-sources). ## Auto-resolve alerts Some alert sources — such as email sources or tools that don't send resolve payloads — will leave alerts in a `Firing` state indefinitely. Auto-resolve lets you set a timeout after which these alerts are automatically resolved. When enabled on an alert source, any alert that remains in `Firing` status will be resolved after the configured duration. The timer starts from when the alert first fires, and the duration is selected from the **Resolve after** dropdown in the alert source configuration. **To enable auto-resolve:** 1. Using the sidebar, navigate to **Settings → Alerts** 2. Select the alert source you want to configure 3. Toggle **Auto-resolve alerts** on 4. Under **Resolve after**, choose a duration from the dropdown (e.g., 3 hours) 5. Click **Save** When an alert is auto-resolved, any associated escalations are cancelled and triage incidents can be auto-declined, following your [alert route](/on-call/alert-routing) configuration. ### Skip auto-resolve for active incidents You can optionally enable `skip auto-resolve if alert is attached to an active incident`. When this toggle is on, alerts that are attached to an active incident will not be auto-resolved — even if the configured duration has elapsed. The alert will remain in `Firing` status for as long as the incident is active, and will only resolved as usual once the incident is no longer active. If the alert is detached from the incident the auto-resolve timer will restart. This is useful when an alert is being actively investigated as part of an incident and you don't want it to silently resolve while responders are still working on it. Auto-resolve only applies to alerts created **after** the setting is enabled. Existing alerts that are already firing will not be affected by changes to the auto-resolve configuration. ## Troubleshoot alert sources Use the Inspect feature to diagnose payload and transformation issues. Click **Inspect** on any alert to view the original payload, JavaScript expressions, and extraction results. Edit attribute expressions to add fallbacks for unexpected payloads or fix catalog entry mappings. ### Request log From the alert source configuration screen, you can view all inbound requests — including ones that were deduplicated, malformed, or rate-limited. This makes it easier to understand why a request didn't result in an alert. This applies to alert sources that receive HTTP requests, but not to integration-based sources, incoming calls, or email sources. ## FAQs Unlimited. All plans support connecting multiple monitoring tools simultaneously. No. Native sources use fixed parsing logic. Use attribute expressions or create a custom HTTP source for custom extraction. Native sources update automatically. For custom HTTP sources, update transform expressions to match the new payload structure. Yes. Test alerts during alert source setup, and optionally create a test alert route that declines or silences all alerts. No native heartbeat monitoring. Use third-party uptime monitoring services (Checkly, Cronitor, Uptime.com, Pingdom) with native alert sources, or send heartbeat signals via custom HTTP alert sources. Check any of the following; wrong payload format, authentication issues, firewall blocking, or rate limiting in your monitoring tool. Auto-resolve only applies to alerts created after the setting is enabled. If you have existing firing alerts, they will not be automatically resolved. You can resolve them manually from the dashboard, mobile app, or Slack/Microsoft Teams. Auto-resolve is most useful for alert sources that don't send resolve payloads, such as email sources or custom HTTP sources from tools that only send firing notifications. Sources like Datadog or Grafana typically send their own resolve events, so auto-resolve is less necessary. If you have enabled `skip auto-resolve if alert is attached to an active incident`, the alert will not be auto-resolved while the incident is active. Once the incident is no longer active, or the alert is detached from the incident, auto-resolve will apply as normal.