Integrations
Integrations connect Autoheal agents to the rest of your stack: code and CI/CD, infrastructure, observability, data stores, security scanners, incident and on-call tools, collaboration, docs, and task management. Every agent uses them, including Incident Response, Alert Triage, Vulnerability Remediation, AI Coding Cost Efficiency and your custom agents.
Each integration is registered once in the tool gateway, which scopes and audits it for every agent. Many integrations also feed the Catalog, importing services, teams, people and repositories into the context graph.
Some integrations (such as Grafana and Coralogix) can be used as both data sources and alert sources.
Autoheal uses the Model Context Protocol (MCP) to communicate with integrations. MCP is an open standard that defines how AI agents connect to external tools and data sources. Each integration exposes specific tools, such as "query metrics" or "search logs". An agent can only call a tool that the integration exposes and that is granted to the agent.
Access and governance
Access has two layers. The credential you connect sets the ceiling: an agent can never do more than the credential allows. The agent's grants decide what each agent may use within that ceiling.
- Read-only by default. Many integrations ship only read tools. Where an integration has write tools, a custom agent uses them only when granted write access to that integration. See Tools.
- Approval. Governance policies pause any matching tool call until a person approves it. With no rules, allowed calls run without approval, so most organizations start with a rule on Operation type is write.
- Audit. Every tool call is recorded in the Audit Trail.
- Platform status updates. Autoheal posts status updates to the ticket that started an investigation, such as a ServiceNow work note or a Jira comment. The platform sends these updates, not an agent tool call. For this reason, approval policies don't apply to them.
Available Integrations
| Integration | Category | Description |
|---|---|---|
| AWS | Infrastructure | CloudWatch logs/metrics, EC2, ECS, EKS, ElastiCache (OIDC federation or instance role) |
| AWS Private Access (SSM) | Network access | kubectl access to private EKS clusters via SSM tunnel |
| Azure Cloud | Infrastructure | VMs, AKS, Storage, Azure Monitor, Log Analytics, Activity Log, Resource Graph (Workload Identity Federation / managed identity) |
| Azure DevOps | Code and CI/CD | Azure Repos, Pipelines, Wiki (read access) |
| BigQuery | Data stores | Query BigQuery datasets via linked GCP integration |
| Bitbucket | Code and CI/CD | Code context, pull requests, pipeline information |
| Chronosphere | Observability | Metrics, logs, traces, monitors, webhook alert forwarding |
| ClickHouse | Data stores | SQL analytics queries |
| Cloudflare | Infrastructure | Zones, DNS records, account settings, alert history |
| Confluence | Docs | Wiki pages, spaces |
| Coralogix | Observability | Log search, metrics querying, alert monitoring |
| Custom Alert Source | Alert sources | Ingest alerts from any system that can POST JSON to a webhook |
| Custom MCP | Custom | Your own MCP servers |
| Databricks | Data stores | SQL queries, job monitoring, clusters |
| Datadog | Observability | Metrics, APM, logs, incidents |
| Drata | Security and compliance | Failing monitoring tests + affected resources, controls, framework readiness, risks (read-only data source) |
| Dynatrace | Observability | Problems, metrics, logs, traces, sessions, entities, Davis alert forwarding |
| Elasticsearch | Observability | Log search, aggregations |
| Featurebase | Customer support | Flagged posts escalate to investigations (alert source). Read posts, comments, and changelogs (data source) |
| Fullstory | Product analytics | Session replay, AI session summaries, frontend error events |
| GitHub | Code and CI/CD | Code, PRs, deployments, Actions |
| GitLab | Code and CI/CD | Code, MRs, pipelines |
| Google Cloud Platform (GCP) | Infrastructure | Credential-free GCP access via OIDC federation |
| Grafana | Observability | Dashboards, metrics, alerts, webhook alert forwarding |
| Honeycomb | Observability | Traces, events, queries |
| Jenkins | Code and CI/CD | Build status, pipeline logs, deployment history |
| Jira | Task management | Issues, webhooks, automated investigation |
| Jira Service Management | Incident and on-call | Service-desk requests (request type, SLA, queues), on-call lookup, webhooks, automated investigation |
| LaunchDarkly | Feature flags | Flag states, targeting rules, changes |
| Microsoft Teams | Collaboration | @mention investigations in a channel |
| MS SQL Server | Data stores | SQL queries, logs, metrics |
| Neo4j | Data stores | Graph database, knowledge graphs |
| Notion | Docs | Pages, databases |
| OpenSearch | Observability | Log search, PPL/SQL queries, alerting monitor webhooks |
| PagerDuty | Incident and on-call | Incidents, on-call, alerts, schedule and escalation policy import |
| PostgreSQL | Data stores | SQL queries, logs, metrics |
| PostHog | Product analytics | HogQL queries, session replay, error tracking, feature flags, deploy annotations |
| Prometheus | Observability | PromQL metric queries, metric/label discovery, Alertmanager alert forwarding |
| Pumble | Collaboration | Send messages to channels via webhooks |
| Pylon | Customer support | Ticket investigation, internal notes |
| ReadMe Docs | Docs | Search and read documentation |
| Recall.ai | Collaboration | Read a meeting bot's logs and reconstruct its lifecycle (creation, join, recording, deletion) (data source) |
| RiverMuse (RightITnow ECM) | Incident and on-call | Event-correlated alert console: search alerts, run saved team filters, read the raw events behind them |
| Sentry | Observability | Errors, exceptions, performance |
| ServiceNow | Incident and on-call | CMDB topology, incidents, changes, SME routing, catalog sync, incident alert forwarding |
| Slack | Collaboration | @mention investigations, alerts |
| Snyk | Security and compliance | Org-wide vulnerability inventory (issues by severity + fixability with upgrade path), monitored projects and their owning repos, and per-project SBOMs (read-only data source) |
| SonarQube | Security and compliance | Quality gate status, issues (new-code filter), security hotspots, coverage/duplication measures (read-only data source) |
| Tailscale | Network access | Private network access to tailnet services via ephemeral sandbox nodes |
| Temporal | Infrastructure | Workflows, task queues, schedules (read-only commands) |
| Vantage | Cost | Cost anomaly investigation, cost reports, recommendations (data source) |
| Zoom | Collaboration | Incident war rooms, meeting management |
General Setup Process
All integrations follow a similar setup process:
From the Autoheal sidebar, click Integrations.
Click on the integration you want to add from the available list.
Give your integration a descriptive name (e.g., "Production Datadog", "Staging Grafana").
Provide the required credentials. These typically include:
- API Key or Token
- Base URL (for self-hosted instances)
- Additional configuration options
Click Test Connection to check that the integration is configured correctly.
Click Save to activate the integration.
Security & Credentials
Credential Storage
- Credentials are stored in your deployment's secrets manager and isolated per organization. The secrets manager is AWS Secrets Manager on SaaS and AWS BYOC, and Azure Key Vault on Azure BYOC
- Access is scoped to your organization only
- Credentials are never logged or included in error messages
Best Practices
Use Service Accounts
Create dedicated service accounts or API keys for Autoheal rather than using personal credentials. This makes it easier to:
- Audit access
- Rotate credentials
- Limit permissions
Principle of Least Privilege
Grant only the permissions Autoheal needs:
- Read-only access is sufficient for most integrations
- Avoid granting write or admin permissions unless necessary
Regular Rotation
Rotate API keys periodically:
- Set calendar reminders for key rotation
- Update credentials in Autoheal immediately after rotation
- Test the connection after updating
Multiple Instances
You can connect multiple instances of the same integration type. Common use cases:
- Production vs Staging - Separate Datadog accounts for different environments
- Regional Instances - Different Grafana instances per region
- Team-Specific - Dedicated monitoring for different teams
Each instance appears as a separate integration that you can grant to agents independently.
Troubleshooting
Connection Failed
Invalid API Key
- Check that the API key is correct and hasn't been rotated
- Check that the key has the required permissions
- Check that the key hasn't expired
Network/Firewall Issues
- Check that Autoheal can reach your integration's API endpoint
- On SaaS, check that your firewall allows connections from Autoheal. Contact support for the current egress addresses. On BYOC, check the network path from your deployment
- For self-hosted tools, ensure the URL is accessible
Permission Denied
- Check that the API key has read permissions
- Check organization-level access controls
- Some integrations require specific scopes or roles
Integration Not Available to an Agent
- Check that the integration status shows as Connected
- Check that the integration is enabled (not disabled)
- Check that your user has permission to access the integration
- Check that the agent has been granted this integration. See Tools