# Overview Cleric uses standard CLIs and APIs (`kubectl`, `gh`, `aws`, etc.) to query your infrastructure. An **Integration** is a credential configuration that authenticates Cleric with a specific system. You provide credentials once (API keys, tokens, service accounts), and Cleric uses them for all investigations. Most integrations require read-only access, though for some we suggest certain write permissions for enhanced functionality. ## Supported Capabilities The table below shows what data Cleric can access from each integration. | Integration | Data Type | Example Tasks | Common Use Cases | | ------------------------------ | -------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------- | | **Amazon Web Services** | Logs | Query CloudWatch logs | Debugging applications, analyzing Lambda executions | | | Metrics | Query CloudWatch metrics | Resource utilization, performance monitoring | | | Resources | Describe EC2 instances, ELBs, Route 53 DNS, ACM certificates | Infrastructure state, DNS configuration, certificate management | | **Confluence** | Documentation | Retrieve pages from a space, get content of a page | Runbooks, architecture documentation | | **Jira** | Issues | Search issues, get issue details with comments and attachments | Incident history, ticket context | | | Actions | Create issues (requires "Create Issues" permission) | Filing tickets from investigation findings | | **Datadog** | Metrics | Query metrics, list metrics, get metric details | Detecting anomalies, performance degradation | | | Logs | Search and analyze logs, get service tags from logs | Identifying application errors | | | Monitors | Get monitor details | Understanding alert context | | | Dashboards | List dashboards by URL or title | Leveraging existing team context | | | SLOs | Get SLO details | Tracking service reliability | | **Elastic Kubernetes Service** | Events | List events | Detecting deployment issues | | | Logs | Search logs for pods | Identifying application errors, startup issues | | | Resources | List, get, and describe resources (pods, deployments, etc.) | Detecting deployment issues, pod crashes, scaling problems | | | Metrics | Get CPU/memory usage for pods and nodes | Resource contentions, quota exceedances | | **Elasticsearch** | Search Indices | List indices, get field mappings | Understanding data structure | | | Logs | Search with query DSL | Searching application logs, analyzing indexed data | | **GitHub** | Repositories | Get code diff, get commit history, search code, create branches | System context, change history, proposed fixes | | | Issues & PRs | Create issues, open pull requests | Tracking problems, proposing code changes | | | Logs | Analyze workflow logs | Identifying deployment errors | | **Google Cloud Platform** | Logs | Search and filter logs, retrieve log labels | Debugging applications, monitoring cloud infrastructure | | | Metrics | Query Cloud Monitoring metrics | Resource utilization, performance monitoring | | | Resources | Describe Compute instances, Load Balancers, Cloud DNS, Certificate Manager | Infrastructure state, DNS configuration, certificate management | | **Grafana** | Metrics | Query metrics | Detecting anomalies, performance degradation | | | Logs | Search Loki logs | Identifying application errors | | | Alert Rules | List alert rules, get alert rule details by UID | Understanding alert context | | | Dashboards | Get dashboard by UID | Leveraging existing team context | | **Kubernetes** | Events | List events | Detecting deployment issues | | | Logs | Search logs for pods | Identifying application errors, startup issues | | | Resources | List, get, and describe resources (pods, deployments, etc.) | Detecting deployment issues, pod crashes, scaling problems | | | Metrics | Get CPU/memory usage for pods and nodes | Resource contentions, quota exceedances | | **PagerDuty** | Incidents | Get incident details | Alert patterns, on-call load analysis | | | Services | Get service details | Understanding service health | | **Prometheus** | Metrics | Query metrics, list metrics, get metric details | Performance monitoring, resource usage | | | Alert Rules | Get active alert rules, get alert rule details | Understanding alert context | | **Generic MCP** | Custom | Tools defined by the connected MCP server | Extending Cleric with custom data sources | ## MCP Support Cleric integrates with the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) in two directions: * **Generic MCP (Cleric as MCP client):** Cleric connects to an MCP server you run and calls its tools during investigations. See the [Generic MCP](/integrations/supported-integrations.md#generic-mcp) section of Supported Integrations. * **Cleric MCP Server (Cleric as MCP server):** Cleric exposes an MCP endpoint at `/mcp` that AI coding tools such as Claude Code and Cursor connect to for reading investigation data and creating new investigations. Authenticates with a per-user API key generated from the Settings page. See [MCP Server](/integrations/mcp.md) for setup. ## Monitoring Integration Health Cleric runs a read-only health check against each configured integration every hour. It tests the connection to the integration's API using the stored credentials. Each integration on the Integrations page displays a status badge: * **Connected**: The last health check succeeded within the past 2 hours * **Error**: No successful health check in the past 2 hours, or the most recent connection test failed When any enabled integration is in the "Error" state, a red indicator appears on the **Integrations** tab in the sidebar. Open the Integrations page to identify which integration is failing. ### Common Causes of Health Check Failures * Expired or rotated API tokens/credentials * Network connectivity changes (firewall rules, IP allowlists) * The external service is temporarily unavailable * Credential permissions were revoked To fix a failing integration, update the credentials and click **Update configuration** to save. ## Enabling and Disabling Integrations Each integration has an **Enable configuration** toggle at the bottom of its configuration form. Disabled integrations are not used during investigations and are not health-checked. They display a **Disabled** badge. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.cleric.ai/integrations/overview.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.