Supported Integrations

Configuration instructions for each integration

You can add integrations yourself in the web app, or configure Cleric MCP and have your coding agent add them for you. Your agent needs access to the systems you want to connect and permission to configure them.

To configure connections in the web app:

1. Log in to the Cleric web app (<your-company>.app.cleric.ai)

2. Click on the "Integrations" tab

3. For each integration (Kubernetes, Datadog, Splunk, MongoDB Atlas, PagerDuty, etc):

   • Click on the integration name

   • Click "Add connection" or "Connect {integration}"

   • Fill in the required fields

   • Click "Save connection"

Repeat this process for each integration you want to set up.

Slack

Slack is the primary way to interact with Cleric. Connect your Slack workspace to start investigations automatically and interact with Cleric from Slack.

The Cleric app is not listed in the Slack Marketplace. You install it from the Cleric web app, and Slack may show a notice that the app is not approved by Slack.

Steps to Configure

1

Connect your Slack workspace

In the Cleric Web app, go to Integrations and click "Add to Slack" in the Slack section to connect your workspace.

2

Invite Cleric to channels

In Slack, add Cleric to channels where you want to run investigations using /invite @Cleric #channel.

3

Start investigating

You can start investigations in two ways:

• On-demand: Mention @Cleric in any channel or thread where Cleric is present

• Automatically: Configure triggers to start investigations on matching alerts or on a schedule (see Configuring Automations)

What This Enables

Once Slack is connected, you can interact with Cleric directly in your channels:

@Cleric Check the health of the checkout service

@Cleric Why is pod checkout-abc123 crashing?

@Cleric Show me error logs for the last hour

@Cleric What changed in the last deployment?

Cleric responds in threads, keeping conversations organized. You can attach files (logs, screenshots, config files) to provide additional context.

Amazon Web Services

How it Works

The AWS integration uses AssumeRole to generate temporary credentials for a role you provision. Cleric never stores long-term AWS credentials.

When investigating, Cleric assumes the role, receives temporary credentials, and accesses only what the role's policies allow.

Required Information

• IAM Role ARN

• Default AWS Region

• Description (to identify the account)

Steps to Configure

1

Get the trust policy from Cleric

• In the Cleric Web UI, navigate to "Integrations" > "Amazon Web Services"

• Copy the trust policy template displayed on the configuration page

• This trust policy allows Cleric to assume the role you'll create

2

Create the IAM role in your AWS account

• Sign in to the AWS Console and navigate to IAM > Roles

• Click "Create role"

• Select "Custom trust policy" and paste the trust policy from step 1

• Click "Next"

3

Attach the validation policy

Create and attach a policy that allows Cleric to validate that the role does not grant write permissions. Use the following policy template, replacing $your_account_id and $your_cleric_roles_name with your values:

{
  "Statement": [
    {
      "Action": [
        "iam:GetRole",
        "iam:ListAttachedRolePolicies",
        "iam:ListRolePolicies",
        "iam:GetRolePolicy"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:iam::$your_account_id:role/$your_cleric_roles_name",
      "Sid": "ReadOwnRoleAndInlinePolicies"
    },
    {
      "Action": ["iam:GetPolicy", "iam:GetPolicyVersion"],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:iam::aws:policy/*",
        "arn:aws:iam::$your_account_id:policy/*"
      ],
      "Sid": "ReadPoliciesAttachedToSelf"
    }
  ],
  "Version": "2012-10-17"
}

• In the AWS Console, navigate to IAM > Policies > Create policy > JSON

• Paste the policy above (with your values substituted)

• Name the policy (e.g., "ClericValidationPolicy") and create it

• Return to your role creation and attach this policy

4

Attach read-only permissions

Attach AWS managed policies to grant Cleric read access to the resources you want it to investigate. We recommend starting with:

• arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess

• arn:aws:iam::aws:policy/CloudWatchLogsReadOnlyAccess

• arn:aws:iam::aws:policy/ElasticLoadBalancingReadOnly

• arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

• arn:aws:iam::aws:policy/AWSCloudTrail_ReadOnlyAccess

AWSCloudTrail_ReadOnlyAccess lets Cleric read your CloudTrail event history (cloudtrail:LookupEvents) to find AWS API calls that failed or changed configuration around an alert, such as a denied call, a deleted branch or an edited security group. To grant only that, attach a policy allowing cloudtrail:LookupEvents on "Resource": "*" instead. Cleric reads the event history CloudTrail keeps for every account (management events, last 90 days); it does not need a trail or access to its S3 bucket.

If you have ECS or EKS clusters to connect, create customer-managed policies via IAM > Policies > Create policy > JSON, then attach to the role like the validation policy in step 3.

For ECS clusters: Add a policy with the following permissions and attach it to the role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ecs:Describe*", "ecs:List*"],
      "Resource": "*"
    }
  ]
}

For EKS clusters: If you plan to connect EKS clusters using the Elastic Kubernetes Service integration, add a policy with the following permissions and attach it to the role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["eks:Describe*", "eks:List*"],
      "Resource": "*"
    }
  ]
}

Note: You can restrict the Resource block to specific cluster ARNs if you want to limit which clusters Cleric can access (e.g., "arn:aws:eks:us-east-1:123456789012:cluster/my-cluster").

You can start with whatever permissions you're comfortable with and add more later. Cleric will automatically pick up new permissions without requiring reconfiguration.

5

Complete role creation

• Add a name for the role (e.g., "ClericRole")

• Optionally add a description

• Click "Create role"

• Copy the role ARN from the role summary page

6

Configure the integration in Cleric

• In the Cleric Web app, navigate to "Integrations" > "AWS"

• Click "Add connection"

• Enter the following information:

  • IAM Role ARN (from step 5)

  • Description (to identify this AWS account)

  • Default Region (e.g., "us-east-1")

• Click "Save connection" to add the integration (this step will verify that you have only granted read-only permissions)

Multiple AWS Accounts

If you want to give Cleric access to multiple AWS accounts, repeat the configuration process for each account. Create a separate role in each account with the same trust policy, then add a separate integration connection for each account.

What This Enables

With AWS connected, Cleric can investigate infrastructure and application issues:

Query CloudWatch logs for checkout-service errors in the last 2 hours

Show me Lambda execution failures since midnight

What's the CPU utilization trend for our EC2 instances today?

Check if there are any unhealthy targets in the production load balancer

Search CloudWatch logs for "timeout" errors across all services

Cleric automatically correlates AWS infrastructure state with application behavior, helping identify issues like resource exhaustion, configuration problems, or service disruptions.

Amplitude

Connect Amplitude to let Cleric correlate product-analytics signals (event volumes, active/new user counts, segmentation, and saved charts) with an incident. For example, Cleric can check whether a key product event dropped when an alert fired, or whether active users fell off around a deploy.

Prerequisites

• An Amplitude project

• The project's API Key and Secret Key (project-scoped, not personal user tokens). Because these keys belong to the project rather than an individual, they keep working when team members leave.

Read-only note. Amplitude's API Key / Secret Key pair grants full project access and Amplitude provides no way to scope it to read-only or to introspect its permissions. Cleric only ever issues read-only Dashboard REST and Export API requests (event lists, segmentation, user counts, saved charts, annotations) and never calls ingestion, taxonomy-write, or user-deletion endpoints. Because of this, Cleric cannot verify read-only access at setup time the way it does for integrations that expose token scopes. Treat the Secret Key as sensitive and store it only in Cleric.

Required Information

• API Key: from Settings > Projects > your project > General

• Secret Key: shown alongside the API Key on the same page

• Base URL: select US (https://amplitude.com, default) or EU (https://analytics.eu.amplitude.com), matching your project's data residency

Steps to Configure

1

Find your project's API Key and Secret Key

• In Amplitude, open Settings > Projects and select the project Cleric should access

• On the General tab, copy the API Key and the Secret Key

2

Determine your base URL

• If your project uses Amplitude's EU data center, select EU for Base URL in Cleric; otherwise use US

3

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations > Amplitude

• Click Add connection

• Select the Base URL, then enter the API Key and Secret Key

• Click Save connection to verify access

What This Enables

With Amplitude connected, Cleric can investigate whether product behavior changed around an incident using the Dashboard REST API.

Did the "Send Email" event volume drop when this alert fired?

Were active users lower than usual during the outage window?

Is there an Amplitude annotation (deploy/launch) near the time this started?

Cleric reads Amplitude through the Dashboard REST API only (event lists, event segmentation, active/new user counts, saved charts, and annotations). It cannot send events, modify taxonomy, or delete user data.

Atlassian

Required Information

• Atlassian base URL

• Atlassian username or email

• Atlassian API token

• Optional list of Confluence space keys

• Optional list of Jira project keys

Steps to Obtain Credentials

Atlassian API tokens inherit the permissions of the user who creates them. We recommend using a dedicated Atlassian user with read-only access to only the Confluence spaces and Jira projects you want Cleric to access.

1

Decide which Confluence spaces and/or Jira projects you want Cleric to access

• Identify the Confluence space keys for those spaces

• Identify the Jira project keys for those projects

2

Create a dedicated Atlassian user with limited access

• Create a new Atlassian user (e.g., "cleric-readonly")

• Grant it read-only access to only the selected spaces by following this doc

• Grant it browse/read access to selected Jira projects. The default Viewer role in the Jira Space (f.k.a. Project) Settings should suffice.

• If you want Cleric to be able to open Jira tickets, you'll need to grant the user (or the group it belongs to) the "Create Issues" permission on the relevant Jira project

  • The easiest way to do this is to create a custom role in the Jira Space settings that includes both "Collaborate" and "Create" permissions

3

Create an API token for that user and configure Cleric

• Go to Atlassian account settings > "Security" > "Create and manage API tokens"

• Create a new API token for the new user and copy it

• Use the following in the integration:

  • Atlassian base URL (e.g., "https://your-instance.atlassian.net")

  • The new user's username or email

  • The new user's API token

  • Provide at least one of:

    • The list of Confluence space keys you selected

    • The list of Jira project keys you selected

What This Enables

With Atlassian connected, Cleric can reference your team's documentation and issue history during investigations:

What does our deployment runbook say about rollback procedures?

Search Confluence for the incident response process

Check our architecture docs for how the checkout service connects to the payment gateway

What are our on-call escalation procedures according to the wiki?

Show me recent incidents in Jira project SRE related to checkout timeouts

Find Jira issues linked to deployment failures in the PAY project

Cleric uses Confluence documentation and Jira issue context to understand your team's processes, architecture decisions, and historical incident patterns, making investigations more context-aware.

Bitbucket Cloud

Connect Bitbucket Cloud to let Cleric inspect source code, commits, pull requests, and Bitbucket Pipelines during investigations. Cleric can also create a branch, push a requested change, and open a pull request for review.

Prerequisites

• Administrator access to the Bitbucket workspace you want to connect

• A repository URL from that workspace, which you can use to find the workspace slug

This integration supports Bitbucket Cloud. It does not support Bitbucket Data Center or Bitbucket Server.

Steps to Configure

1

Create an OAuth client

In Bitbucket Cloud:

1. Open the workspace you want Cleric to access.

2. Select the settings cog, then Workspace settings.

3. Under Apps and features, select OAuth clients.

4. Select Create OAuth client.

5. Enter Cleric as the name and complete any other required fields.

If Bitbucket requires a callback URL, enter https://www.cleric.ai. Cleric does not redirect to this URL when using Client credentials.

2

Configure permissions

Under Authorization, select Client credentials.

Under Scopes, select:

Permission	Access
Repositories	Write
Pull requests	Write
Pipelines	Read

Leave the remaining permissions unset. Select Save, then copy the generated Client ID and Client secret.

3

Add the configuration in Cleric

In Cleric, go to Integrations > Bitbucket and select Add connection. Enter:

• Workspace slug: The first path segment after bitbucket.org in a repository URL. For example, if the repository URL is https://bitbucket.org/acme/checkout-service, enter acme.

• Client ID: The Client ID from the Bitbucket OAuth client.

• Client secret: The Client secret from the same OAuth client.

Select Test connection. When the test succeeds, select Save connection.

Treat the Client secret like a password. Enter it only in Cleric.

What This Enables

With Bitbucket connected, Cleric can investigate code and CI/CD activity:

What changed in the last deployment of checkout-service?

Show me the code diff for the most recent commit to main

Why did the last three Bitbucket Pipelines runs fail?

Was this regression introduced by a recent pull request?

Fix the timeout handling and open a pull request for review

Cleric only pushes changes to a new branch and opens a pull request when you request a code change. It does not merge pull requests or push directly to the default branch.

Multiple Workspaces

Create a separate OAuth client and Cleric configuration for each Bitbucket workspace.

Troubleshooting

• Bitbucket rejects the credentials: Verify the Client ID and Client secret, and confirm that Client credentials is enabled on the OAuth client.

• The connection shows an error: Verify the workspace slug and the three required permissions, then test the configuration again.

• A repository is missing: Confirm that you created the OAuth client in the workspace that owns the repository.

For more information, see Use OAuth on Bitbucket Cloud and Bitbucket Cloud REST API scopes.

BuildKite

Connect BuildKite to let Cleric inspect CI/CD pipelines, builds, jobs, build logs, and annotations to diagnose failing deploys and pipelines.

Prerequisites

• A BuildKite organization

• A BuildKite user account for Cleric to authenticate as. BuildKite API access tokens are owned by the user who creates them, so we recommend using a shared service-account user rather than an individual's account. Personal tokens stop working when that user is removed from the organization.

• A REST API access token created from that account, restricted to your organization and to read scopes only. Cleric validates the token scopes during setup and rejects tokens that include any write or delete scope.

Required Information

• BuildKite organization slug (from your dashboard URL https://buildkite.com/<org-slug>)

• A BuildKite API Access Token with these scopes (exact dashboard names):

  • Read Builds

  • Read Build Logs

  • Read Pipelines

  • Read Organizations

Steps to Configure

1

Create a read-only API access token

• Sign in as a shared service account and open API Access Tokens (User Settings > API Access Tokens)

• Click New API Access Token

• Under Organization Access, restrict the token to the organization Cleric should see

• Under REST API Scopes, enable only: Read Builds, Read Build Logs, Read Pipelines, Read Organizations

• Leave GraphQL API access disabled and do not enable any write scopes

• Create the token and copy its value

2

Find your organization slug

• Open your BuildKite dashboard and copy the slug from the URL https://buildkite.com/<org-slug>

3

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations > BuildKite

• Click Add connection

• Enter the organization slug and API access token

• Click Save connection to verify access

What This Enables

With BuildKite connected, Cleric can investigate CI/CD failures by finding failing builds across pipelines, branches, or commits, drilling into job logs, and reading build annotations.

Why did the latest deploy pipeline build fail on main?

Show the failing job's log for build #1234 of the api pipeline

Did this CI failure start after a specific commit?

Cleric reads BuildKite through the REST API only. It cannot create, retry, cancel, or modify builds, and it does not access Secrets, Packages and Registries, or Test Engine data.

ClickHouse

Connect a ClickHouse server or ClickHouse Cloud service so Cleric can see what it is doing during an investigation: failing and slow queries, failing inserts, too many parts, stuck merges and mutations, replication, memory and disk. When you grant it, Cleric can also query data you store in ClickHouse, such as logs and events. Cleric's access is read-only.

How it Works

Cleric queries ClickHouse over its HTTP interface with a user you create for it. Every query Cleric sends:

• runs with readonly = 1, so the server refuses writes, DDL and SET, and a query cannot raise Cleric's limits;

• stops after 30 seconds and returns at most 1,000 rows;

• runs as a single statement, with values passed as typed query parameters.

Cleric also refuses queries with a SETTINGS clause, and table functions that read from outside the server (url, s3, file, remote and similar). The password is used only by Cleric's own service. It is never passed to the agent's sandbox.

ClickHouse keeps a history of every query in system.query_log, so Cleric can look at the time of the incident itself, not only at the server's state when it looks.

Required Information

• Host: the HTTP interface URL with its port, for example https://abc123.us-east-1.aws.clickhouse.cloud:8443 or http://clickhouse.internal:8123

• Database: the default database for queries (usually default)

• CA Certificate: only if the server's certificate is not signed by a public CA (see Encryption)

• Username and Password of a user created for Cleric

Permissions

Create a dedicated user that can only read the system tables, plus any databases whose data you want Cleric to query:

CREATE USER cleric IDENTIFIED WITH sha256_password BY '<a strong password>';
GRANT SELECT ON system.* TO cleric;

-- Optional: on a cluster (including every ClickHouse Cloud service), read all replicas' query logs
GRANT READ ON REMOTE TO cleric;

-- Optional: data Cleric may query, for example logs and events
GRANT SELECT ON logs.* TO cleric;

Don't give the user a readonly settings profile. Cleric makes every query read-only itself. A profile pinned to readonly = 1 also stops Cleric from applying its time and row limits and returning UTC timestamps. If your policy requires a profile, use readonly = 2.

When you save the connection, Cleric reads the user's grants, including grants through roles, and rejects the user if it holds anything beyond SELECT (and READ ON REMOTE). That includes INSERT, ALTER, CREATE, DROP, TRUNCATE, SYSTEM, KILL QUERY, access management, and reading from URLs, files or S3. ClickHouse Cloud's default user fails this check. Use a dedicated user.

Network Access

• ClickHouse Cloud or a public endpoint: add Cleric's static egress IP to the service's IP access list or your firewall.

• Private server: use the Cleric Connector. Add the server's host and HTTP port to the Connector's endpoints, then enter the same URL in Cleric.

Encryption

Use https:// with the HTTPS port (8443 by default). Cleric verifies the server's certificate against public CAs, or against the CA certificate you paste, base64-encoded:

base64 < ca.pem | tr -d '\n'

Use http:// only for a server reachable only on a private network or through the Cleric Connector.

Supported and Unsupported Data

Cleric reads:

• Query history: system.query_log, including failures by error code, slow statements, users and tables

• Running queries: system.processes

• Server errors: system.errors

• Storage: system.parts, system.merges, system.mutations, system.disks, and table sizes and settings

• Replication: system.replicas, system.replication_queue, system.distribution_queue, and the Keeper connection

• Resource history: system.metric_log, system.asynchronous_metric_log and system.part_log, where enabled

• Your data: tables in databases you granted SELECT on

Cleric never:

• writes data, changes settings, or runs DDL

• kills queries or runs SYSTEM commands

• reads from URLs, S3, files or other servers, except its own cluster's replicas with READ ON REMOTE

Steps to Configure

1

Create the user

Connect as an administrator and run the statements under Permissions.

2

Allow Cleric to connect

Add Cleric's egress IP to the IP access list, or add the server to the Cleric Connector, as described under Network Access.

3

Add to Cleric

In the Cleric Web app, go to Integrations > ClickHouse > Add connection. Enter the host URL, database, CA certificate if needed, username and password, then click Save connection. Cleric connects and checks the user's grants before saving.

What This Enables

Why are inserts into the events table failing?

Which queries failed on ClickHouse in the last hour, and when did it start?

Is ClickHouse running out of memory or disk?

Are any replicas lagging or read-only?

How many checkout errors were logged in the last 30 minutes?

Cloudflare

Connect Cloudflare to let Cleric query DNS records, WAF/security events, Workers, traffic analytics, load balancer health, SSL/TLS status, and audit logs using the Cloudflare API v4 and GraphQL Analytics API.

Prerequisites

• A Cloudflare account

• A read-only API Token with the appropriate permission groups

• Your Account ID

Steps to Configure

1

Create an Account-Level Read-Only API Token

Use account-level API Tokens only. Do not use personal tokens created under My Profile. Those are tied to an individual user and will stop working if that person leaves the organization. Account-level tokens authenticate as the organization, not as a person.

• Log in to the Cloudflare dashboard and navigate to Manage Account > Account API Tokens

• Click Create Token

• Use the Custom token template

• Add these read-only permissions (names match the Cloudflare dashboard exactly):

  Category	Permission	Level
  Account & Billing	Account API Tokens	Read
  DNS & Zones	DNS View	Read
  App Security	Account WAF	Read
  App Security	Account Firewall Access Rules	Read
  Analytics & Logs	Account Analytics	Read
  Analytics & Logs	Account Logs	Read
  Developer Platform	Workers Scripts	Read
  Developer Platform	Workers Observability	Read
  Network Services	Account Load Balancers	Read
  Network Services	Load Balancing: Monitors and Pools	Read
  Cache & Performance	Account SSL & Certificates	Read

  The Account API Tokens: Read scope is required so Cleric can verify that the token has only read-only permissions. Without it, Cleric cannot validate the token's scopes and will reject the connection.

• Under Account Resources, select your account

• Under Zone Resources, select "All zones" or specific zones

• Optionally set an IP filter and expiration date for additional security

• Click Continue to summary then Create Token

• Copy the token immediately. It is only shown once.

2

Find your Account ID

• In the Cloudflare dashboard, your Account ID appears on the right sidebar of any zone's Overview page, or under Account Home

3

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations > Cloudflare

• Click Add connection

• Enter your Account ID and API Token

• Click Save connection to verify access

What This Enables

With Cloudflare connected, Cleric can investigate DNS issues, WAF events, Worker errors, traffic anomalies, and more:

Are there any WAF events blocking traffic to the checkout page?

Show me the DNS records for example.com

What is the error rate for Workers in the last hour?

Were there any configuration changes in Cloudflare around the time of the incident?

Supported and Unsupported APIs

Cleric currently supports the following Cloudflare data surfaces for read-only investigation:

API Surface	Status	What Cleric Can Do
DNS records	Supported	List and query DNS records across zones
WAF / Security events	Supported	Query firewall events (blocked, challenged, logged requests) via GraphQL
Traffic analytics	Supported	HTTP request analytics (status codes, cache rates, bandwidth) via GraphQL
Workers	Supported	List scripts, query invocation analytics (errors, CPU time, duration) via GraphQL
Load balancers	Supported	Pool health, origin status, failover configuration
SSL/TLS	Supported	Certificate packs, verification status, SSL mode
Audit logs	Supported	Account audit trail (who changed what, when)
Zone management	Supported	List zones, status, plan, name servers

The following Cloudflare categories are not currently supported:

Category	Reason
Developer Platform (D1, R2, KV, Pages, Queues, Pipelines, etc.)	Not yet needed for SRE investigation
AI & Machine Learning (AI Gateway, Workers AI, Agents)	Not yet needed for SRE investigation
Cloudflare One / Zero Trust (Access, CASB, Tunnels, WARP)	Not yet needed for SRE investigation
Rules & Configuration (Rulesets, Transform Rules, Redirects)	Not yet needed for SRE investigation
Network Services (Magic Transit, Magic WAN, IP Prefixes)	Not yet needed for SRE investigation
Media (Stream, Images)	Not yet needed for SRE investigation
Email & Messaging (Email Routing, Email Security)	Not yet needed for SRE investigation
Account & Billing (Billing, Notifications, API Gateway)	Not yet needed for SRE investigation

These can be added in future releases as customer needs arise. Each requires adding the corresponding read-only scope to the API token and a new skill script.

Datadog

Required Information

• Host (select your Datadog site from the dropdown)

• Datadog API Key

• Datadog Application Key

Steps to Configure

1

Get your API key

Go to Organization Settings > API Keys. Copy an existing key or create a new one.

2

Determine your Datadog site

When adding the connection in Cleric, select your Datadog site in the Host dropdown. The available options are:

Site	API endpoint
US1	https://api.datadoghq.com
US3	https://api.us3.datadoghq.com
US5	https://api.us5.datadoghq.com
EU1	https://api.datadoghq.eu
AP1	https://api.ap1.datadoghq.com
US1-FED	https://api.ddog-gov.com

To find your site, check the URL when logged into Datadog. The subdomain indicates your region (e.g., us5.datadoghq.com → US5).

3

Create a read-only role

1. Go to Organization Settings > Roles > + New Role

2. Name it Cleric Integration

3. Enable read permissions for the following categories:

   • APM & Traces

   • Continuous Profiler

   • Logs

   • Dashboards

   • Notebooks

   • Monitors

   • SLOs

   • Incidents & Cases

   • Error Tracking

   • Events

   • RUM & Session Replay

   • Synthetics

   • Database Monitoring

   • CI/CD Visibility

   • Cloud Cost Management

   • Infrastructure

   • Security Signals

4. Do not grant any write, edit, or delete permissions

5. Click Save

4

Create a service account

1. Go to Organization Settings > Service Accounts > + New Service Account

2. Name it cleric-integration and assign the Cleric Integration role

3. Click Create Service Account

4. In the Application Keys section, click + New Key

5. Leave the key unscoped (do not add scopes to the application key; permissions are controlled by the role)

6. Copy the key (you won't see it again)

5

Add to Cleric

In the Cleric Web app, go to Integrations > Datadog > Add connection. Select your Datadog site in the Host dropdown, enter your API Key and Application Key, then click Save connection.

Optional: To restrict Cleric to specific logs, go to Logs > Configuration > Data Access and create a restriction query for the Cleric Integration role (e.g., service:my-app AND env:production). Cleric will only see logs matching that query.

What This Enables

With Datadog connected, Cleric can analyze logs, metrics, monitors, and dashboards:

Show me error logs for checkout-service in the last hour

What caused the most recent "High Memory Usage" alert to fire?

Compare current API latency to baseline using Datadog metrics

Check the system-overview dashboard for anomalies

What services have the highest error rate increase since this morning?

Show me all active monitors for the production environment

Cleric correlates Datadog data across logs, metrics, and alerts to identify patterns and root causes that might not be obvious from individual data points.

Elastic Kubernetes Service

The Elastic Kubernetes Service (EKS) integration allows Cleric to access Kubernetes clusters running on Amazon EKS. This integration combines AWS IAM authentication with Kubernetes RBAC to provide secure, read-only access to your EKS clusters.

Prerequisites

You must have an existing AWS integration configured for the AWS account containing your EKS cluster, with EKS permissions attached to the IAM role.

Required Information

• EKS Cluster ARN

• Host (the API server hostname, found in the EKS console under your cluster's details)

• Description (to identify this cluster)

Steps to Configure

1

Create the ClusterRole

Apply the cleric-role ClusterRole to your EKS cluster. See the Kubernetes integration for the full ClusterRole definition.

2

Create the ClusterRoleBinding

Create a ClusterRoleBinding that assigns the cleric-role to the cleric group:

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cleric-rolebinding
subjects:
  - kind: Group
    name: cleric
    apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cleric-role
EOF

3

Grant the IAM role access to the cluster

Allow your AWS integration's IAM role to authenticate to the cluster as a member of the cleric group. Choose one of the following methods:

Option A: EKS Access Entries (Recommended)

Use EKS Access Entries if your cluster has the API authentication mode enabled. See EKS Access Entries documentation for details.

In the AWS Console:

1. Navigate to your EKS cluster

2. Go to "Access" > "Access entries"

3. Click "Create access entry"

4. Select your Cleric IAM role as the principal

5. Add cleric to the Kubernetes groups

6. Click "Create"

Option B: aws-auth ConfigMap

Use the aws-auth ConfigMap if your cluster uses the ConfigMap authentication mode. See aws-auth ConfigMap documentation for details.

Edit the aws-auth ConfigMap:

kubectl edit configmap aws-auth -n kube-system

Add an entry to the existing mapRoles list (do not replace the entire list):

- rolearn: arn:aws:iam::ACCOUNT_ID:role/YOUR_CLERIC_ROLE_NAME
  groups:
    - cleric

Replace ACCOUNT_ID and YOUR_CLERIC_ROLE_NAME with your values.

4

Configure the integration in the Cleric UI

In the Cleric Web app:

1. Navigate to "Integrations" > "Elastic Kubernetes Service"

2. Click "Add connection"

3. Enter the following information:

   • Cluster ARN (e.g., arn:aws:eks:us-east-1:123456789012:cluster/my-cluster)

   • Host (the API server endpoint from the EKS console, e.g., https://ABCD1234.gr7.us-east-1.eks.amazonaws.com)

   • Description (to identify this cluster)

4. Click "Save connection"

Multiple EKS Clusters

To give Cleric access to multiple EKS clusters:

• Same AWS account: Create the ClusterRole, ClusterRoleBinding, and access entry/ConfigMap mapping in each cluster, then add a separate EKS integration for each cluster.

• Different AWS accounts: Ensure you have an AWS integration for each account, then follow the full configuration process for each cluster.

What This Enables

With EKS connected, Cleric can investigate your Amazon EKS clusters using IAM authentication:

List all pods in the production EKS cluster

Why is the checkout-service pod OOMKilled in the EKS cluster?

Show me node status and resource utilization in the EKS cluster

What deployments changed in the last 24 hours in EKS?

EKS integration provides the same Kubernetes investigation capabilities as the standard Kubernetes integration, but uses AWS IAM for authentication instead of long-lived tokens, providing better security and audit trails.

Elasticsearch

Required Information

• Elasticsearch cluster URL

• Elasticsearch API key

Steps to Obtain Credentials

1

Ensure you have permissions to create API keys

2

Sign in to your Elasticsearch management interface

Sign in to your Elasticsearch management interface (e.g., Kibana)

3

Navigate to API keys

Navigate to "Management" > "Security" > "API keys" and click "Create API key"

4

Create the API key

Enter a name for the key, select "Read-only" under "Control security privileges", then click "Create API key"

5

Note down the encoded API key

Note down the encoded API key for use in the Cleric web app

What This Enables

With Elasticsearch connected, Cleric can search and analyze indexed logs:

Search Elasticsearch for errors related to user 3bc96ec9

Show me all timeout errors in the checkout-service index from the last 4 hours

What are the most common error patterns in production logs today?

Find logs matching "payment failed" and group by error type

Cleric uses Elasticsearch's powerful search capabilities to quickly find relevant logs and identify patterns across large volumes of indexed data.

Generic MCP

The Generic MCP integration lets you connect any Model Context Protocol (MCP) server to Cleric. This extends Cleric's capabilities beyond built-in integrations, allowing it to use custom tools and data sources that your team provides through an MCP server.

No read-only guarantee. Unlike built-in integrations, Cleric cannot verify that a Generic MCP server only exposes read-only operations. The tools available to Cleric are entirely defined by the connected MCP server. It is your responsibility to ensure the MCP server only exposes operations appropriate for Cleric to perform.

How it Works

Cleric connects to your MCP server over HTTP using the Streamable HTTP transport. Once connected, Cleric discovers the tools the server exposes and makes them available during investigations. Cleric's agent decides when to call these tools based on the investigation context.

Required Information

• MCP server URL

• Authorization header (if the server requires authentication)

Authentication

The Generic MCP integration supports HTTP header-based authentication only. You provide a single HTTP header in name: value format. This header is sent with every request to the MCP server.

Common examples:

Auth Method	Header Format
Bearer token	Authorization: Bearer your-token
API key	X-API-Key: your-key
Basic auth	Authorization: Basic base64(user:pass)

If your MCP server does not require authentication, leave the authorization header field empty.

Steps to Configure

1

Ensure your MCP server is reachable

Your MCP server must be accessible from Cleric's network. If the server runs on private infrastructure, configure network access using the Connecting Private Resources guide.

2

Add the integration in Cleric

In the Cleric Web app, go to Integrations > Generic MCP > Add connection. Enter:

• URL: The full URL of your MCP server endpoint (e.g., https://mcp.example.com/mcp)

• Authorization Header: The header value in name: value format (e.g., Authorization: Bearer your-token)

3

Save and verify

Click Save connection. Cleric will test the connection to your MCP server and display a health status.

Multiple MCP Servers

You can connect multiple MCP servers by adding a separate configuration for each. Cleric will discover and use tools from all connected servers during investigations.

What This Enables

With a Generic MCP server connected, Cleric can use whatever tools your server exposes:

Query our internal analytics API for error rates by region

Check the deployment status in our custom release management system

Look up customer configuration in our internal tools

Search our internal knowledge base for known issues related to this error

The specific capabilities depend entirely on the tools your MCP server provides. Cleric treats them like any other integration tool, calling them as needed during investigations.

GitHub

How it Works

The GitHub integration uses a GitHub App for authentication. You select which repositories to grant access during installation. The default permission set is:

Permission	Access	What this allows
Actions	Read-only	View and analyze CI/CD workflow logs
Checks	Read-only	View check run and check suite results
Contents	Read and write	Search code, view commit history and diffs, create branches, push commits
Issues	Read and write	View, create, and comment on issues
Metadata	Read-only	Access repository metadata (names, descriptions, topics)
Pull requests	Read and write	View pull request status and diffs, and open pull requests

The agent primarily uses the gh CLI, authenticated with a short-lived installation token scoped to the App's permissions and the repositories selected during installation. Cleric creates an ephemeral sandbox for each investigation. All working data is stored temporarily and deleted based on your configured retention period. All actions are logged.

Cleric is instructed that it cannot merge pull requests or push directly to your default branch.

We recommend configuring branch protection rules on your default branch. If your organization already requires a pull request with at least 1 approval before merging, that sufficiently restricts the agent. If not, the minimum recommended rule is "Restrict who can push to matching branches" on your default branch, with your team(s) on the allowlist and the Cleric app excluded. The default force push and branch deletion restrictions should also be retained on protected branches.

Prerequisites

Organization owners can install GitHub Apps.

Repository admins can install GitHub Apps if they only grant access to repos they admin. Other organization members can request installation, and GitHub sends a notification to the org owner.

A GitHub organization owner must approve the permissions when installing or updating the Cleric GitHub App. This is done in your GitHub organization settings under Installed GitHub Apps.

Installation Steps

1

Click 'Connect GitHub'

In Cleric web app, go to "Integrations" > "GitHub" and click "Connect GitHub"

2

Select the organization

Select the organization you want Cleric to access

3

Select repositories and authorize

Select repositories and authorize the Cleric GitHub app. Review and approve the requested permissions.

4

Complete installation

After successful installation you will be redirected back to the Integrations page.

What This Enables

With GitHub connected, Cleric can analyze code, deployments, and CI/CD workflows:

What changed in the last deployment of checkout-service?

Show me the code diff for the most recent commit to main

Why did the last 3 web-app pipeline runs fail?

Search the codebase for where we initialize the payment gateway client

What was modified in the authentication flow in the last week?

Check if there are any failing GitHub Actions workflows

With write permissions, Cleric can also take action during investigations:

Create a GitHub issue summarizing this problem and the potential solutions.

Add debug logs to this flow and create a draft PR for me to review.

Open an issue with the error details so the team can track this.

Cleric correlates code changes with production issues, helping identify if recent commits, configuration changes, or CI/CD failures are related to observed problems.

Google Cloud Platform

Required Information

• Project ID

• Service account key (base64 encoded)

Steps to Obtain Credentials

1

Ensure you have the required permissions

Ensure you have the following IAM roles on your GCP project:

• Service Account Creator (roles/iam.serviceAccountCreator) - to create service accounts

• Project IAM Admin (roles/resourcemanager.projectIamAdmin) - to grant roles to the service account

2

Create the service account

1. Sign in to the Google Cloud Console

2. Navigate to IAM & Admin > Service Accounts

3. Click Create Service Account

4. Enter a service account name (e.g., "cleric-integration")

5. Click Create and Continue

3

Grant appropriate roles to the service account

Grant the service account read-only access to the resources you want Cleric to investigate. We recommend starting with these roles (adjust this list to reflect the services you use):

• roles/monitoring.viewer - View Cloud Monitoring metrics

• roles/logging.viewer - View Cloud Logging logs

• roles/container.viewer - View GKE clusters and workloads (if you run on GKE)

• roles/run.viewer - View Cloud Run services, revisions and jobs (if you run on Cloud Run)

• roles/cloudsql.viewer - View Cloud SQL instance configuration (if you use Cloud SQL)

• roles/compute.viewer - View Compute Engine instances

• roles/dns.reader - View Cloud DNS records

• roles/certificatemanager.viewer - View SSL certificates

roles/monitoring.viewer is the most important of these. Cleric builds its inventory of your running services from Cloud Monitoring, so it works even if you grant nothing else. Pick the runtime role that matches how you deploy: roles/container.viewer for GKE, roles/run.viewer for Cloud Run.

Some of these roles allow reading workload definitions, which include environment variables. If you keep secrets inline in environment variables rather than in Secret Manager, take that into account when deciding which roles to grant.

Select each role from the dropdown, then click Continue. You can add more roles later as needed.

4

Complete service account creation

Click Done to create the service account

5

Create and download the JSON key

1. Click on the email address of the newly created service account

2. Go to the Keys tab

3. Click Add Key > Create new key

4. Select JSON as the key type

5. Click Create

The JSON key file will be automatically downloaded to your machine. Store this file securely as it contains credentials that provide access to your GCP resources.

6

Encode the key file

Encode the downloaded JSON key file using base64:

macOS

base64 -i your-service-account-key.json | pbcopy

The encoded key is now in your clipboard. Paste it directly into the Cleric web app.

Linux

base64 -w 0 your-service-account-key.json

Platform-agnostic

cat your-service-account-key.json | base64 | tr -d '\n'

Copy the output string for use in the Cleric web app.

7

Note down the required information for use in the Cleric web app

• Your project ID

• The base64-encoded service account key

What This Enables

With GCP connected, Cleric can investigate infrastructure and application issues:

Query Cloud Logging for errors in the checkout-service in the last 2 hours

Show me GKE cluster health and any node issues

What's the memory utilization trend for Compute Engine instances today?

Check Cloud Monitoring metrics for elevated error rates

Search Cloud Logs for "connection timeout" across all services

Cleric automatically correlates GCP infrastructure state with application behavior, helping identify resource exhaustion, configuration issues, or service disruptions.

Grafana

Required Information

• Grafana server URL

• Service account token (Viewer role)

Steps to Obtain Credentials

1

Ensure you have permission

Ensure you have a Grafana account with permission to create and edit service accounts.

2

Navigate to Administration

Sign in to Grafana and click "Administration" in the left-side menu.

3

Add a service account

Navigate to "Users and access" > "Service accounts" > "Add service account"

4

Create the service account

Enter a Display name, assign the "Viewer" role from the dropdown, and click "Create".

5

Generate the token

Click "Add service account token", enter a name for the token, and click "Generate token".

6

Note down the token value

Note down the token value for use in the Cleric web app.

What This Enables

With Grafana connected, Cleric can query metrics and analyze dashboards:

Query Grafana metrics for API response time over the last hour

Check the system-overview Grafana dashboard for anomalies

Show me Loki logs for errors in checkout-service

What alert rules are currently firing in Grafana?

Compare current memory usage to baseline using Grafana metrics

Cleric uses Grafana to access metrics from Prometheus, Loki logs, and dashboard configurations, helping correlate visual dashboard insights with investigation findings.

Honeycomb

Connect Honeycomb to let Cleric read your triggers, the alert definitions in a Honeycomb environment, and optionally query your data. This lets Cleric tell what condition an alert actually watches, how it is evaluated, and who it pages, and check the data behind it.

Prerequisites

• A Honeycomb team with the environment you want Cleric to read

• Permission to create API keys in that environment (Honeycomb Owner or Manager)

Required Information

• Base API URL: US (https://api.honeycomb.io) or EU (https://api.eu1.honeycomb.io)

• A Honeycomb Configuration key for that environment, with the Triggers permission enabled (see Steps below)

Use a team-owned key, not a personal one. Configuration keys created under Environment settings > API keys belong to the environment, so they keep working when a team member leaves.

Permissions

Honeycomb's permission model does not offer a read-only variant of trigger access. The Triggers permission grants full create/read/edit/delete access to the Triggers API, so Cleric requires it even though Cleric only ever reads. Cleric compensates by refusing over-privileged keys. Connecting fails if the key carries any permission other than:

Checkbox in Honeycomb	Section	Required?	Why Cleric needs it
Triggers	Create, Read, Edit, and Delete	Yes	The only permission Honeycomb offers for reading triggers (grants create/read/edit/delete)
Manage datasets	Data	Optional	Honeycomb also gates listing dataset names behind it. Grant it if you want Cleric to discover your datasets automatically; without it, Cleric reads environment-wide triggers and any dataset it can name from the alert
Queries and columns	Create, Read, Edit, and Delete	Optional	Lets Cleric read and create query definitions and read saved queries. Honeycomb also requires it alongside Run queries to execute queries and retrieve results. Cleric never edits columns, calculated fields, or query annotations
Run queries	Data	Optional	Lets Cleric query your data, such as rerunning the query behind a trigger. Honeycomb offers it on Enterprise plans only

Ingest keys and Management keys are rejected because they cannot read triggers.

Supported and Unsupported APIs

Cleric calls the Honeycomb API v1:

• Key introspection: GET /1/auth (verifies the key and resolves the team and environment)

• Datasets: GET /1/datasets (only if Manage datasets is granted; used to discover dataset names)

• Triggers: GET /1/triggers/{dataset} and GET /1/triggers/__all__

• Query definitions and saved queries (requires Queries and columns):

  • POST /1/queries/{dataset} and GET /1/queries/{dataset}/{id} (create a query from a specification, or read one by ID)

  • GET /1/query_annotations/{dataset} and GET /1/query_annotations/{dataset}/{id} (read the team's saved, named queries)

• Query data (requires both Queries and columns and Run queries):

  • POST /1/query_results/{dataset} and GET /1/query_results/{dataset}/{id} (run a query and read its results)

Cleric never creates, edits, disables, or deletes triggers, never edits columns, calculated fields, or query annotations, and does not send events or read Boards, SLOs, or Markers.

Steps to Configure

1

Create a Configuration key

• In Honeycomb, go to Environment settings > API keys for the environment you want Cleric to read.

• Create a new Configuration key named Cleric.

• Enable Triggers under "Create, Read, Edit, and Delete", and optionally Manage datasets under "Data".

• To let Cleric query your data, also enable Queries and columns under "Create, Read, Edit, and Delete" and Run queries under "Data". Run queries is only available on Honeycomb Enterprise plans.

• Leave every other permission off. Cleric rejects keys with extra permissions.

• Copy the key value.

2

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations > Honeycomb.

• Click Add connection.

• Select the Base API URL (US or EU) and paste the Configuration API Key.

• Click Save connection to verify access.

What This Enables

With Honeycomb connected, Cleric can explain the alert it is investigating instead of guessing at it. This includes the query behind the trigger, the threshold that was crossed, how often it evaluates, and which alerts cover a service. With Queries and columns and Run queries enabled, Cleric can also rerun a trigger's query to see which groups crossed the threshold, and query your data around the alert.

What does this Honeycomb alert actually measure?

Which Honeycomb triggers are firing right now?

What is the threshold on the checkout latency trigger, and how often is it evaluated?

Which Honeycomb triggers cover the payments dataset?

Which groups pushed the queue errors trigger over its threshold?

Cleric cannot read raw events or change any Honeycomb configuration. Without Run queries, it can still read triggers and, with Queries and columns, query definitions and saved queries.

incident.io

Connect incident.io so Cleric can use current and past incidents, updates, alerts, follow-ups, and service ownership to inform an investigation. When you ask, Cleric can add an update or alert note, link its investigation, create a follow-up, or import a post-incident document.

Permissions

Create an organization API key named Cleric so updates it posts appear under Cleric's name in incident.io. You need permission to create API keys under Settings → API keys.

Under Account-level permissions in incident.io, select:

• View data, like public incidents and organization settings

• Edit incidents

• View all incident data, including private incidents

• View catalog types and entries

• View on-call resources like alerts, escalations and schedules

• Manage postmortems, including updating its status

• View incident participant workload

• View incident participant workload, including for private incidents

If the key is missing access, Cleric tells you when you save the connection.

Cleric can add information to an incident when you ask it to. It cannot declare or close incidents or change their status, severity, or summary.

Steps to Configure

1

Create an API key

• In incident.io, open Settings → API keys and click Add new.

• Name the key Cleric and select the eight account-level permissions listed above.

• Copy the key when it is shown. incident.io displays it only once.

2

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations → incident.io.

• Click Add connection and paste the API Key.

• Click Save connection.

What This Enables

For example, you can ask Cleric:

Is there already an incident for this checkout latency alert?

How was INC-742 resolved?

Which team owns payments-gateway?

Post a summary of this investigation to INC-742 and link it there

Create a follow-up on INC-742 for the connection pool fix, assigned to the Payments team

Kubernetes

How it Works

The Kubernetes integration uses a service account with read-only RBAC permissions to access cluster resources, events, and pod logs. Cleric authenticates using a long-lived bearer token and communicates directly with the Kubernetes API server.

The default ClusterRole also grants read access to common add-ons. This is how Cleric works with Argo CD: it reads Argo CD Applications and Argo Rollouts (the argoproj.io API group) through the Kubernetes API to check sync and rollout state. There is no separate Argo CD integration, and Cleric does not call the Argo CD API or CLI.

If your Kubernetes control plane is public, you have the option to request Cleric provide specific IP addresses to allowlist. These IPs are assigned during provisioning, and all Cleric traffic originates from this CIDR range. For private clusters, see Connecting Private Resources.

EKS Users: For Amazon EKS clusters, we offer a native integration that uses IAM authentication instead of long-lived tokens. See the Elastic Kubernetes Service integration for details.

Required Information

• Kubernetes API server address

• Kubernetes CA certificate

• Kubernetes bearer token

Steps to Obtain Credentials

1

Ensure kubectl is configured

Ensure you have access to a Kubernetes cluster and that kubectl is configured to interact with it.

2

Run the configuration commands

Run the following commands in your terminal:

# Create a service account for Cleric
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cleric-sa
  namespace: cleric
automountServiceAccountToken: true
EOF

# Create a ClusterRole with read access to common diagnostic objects but prevents reading the content of secrets.
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cleric-role
rules:
  - verbs: ["list"]
    apiGroups: [""]
    resources: ["secrets"]
  - verbs: ["create"]
    apiGroups: ["authorization.k8s.io"]
    resources: ["selfsubjectaccessreviews", "selfsubjectrulesreviews"]
  - verbs: ["get", "list", "watch"]
    apiGroups:
    # Common / Platform Agnostic
    - admissionregistration.k8s.io
    - apiextensions.k8s.io
    - apiregistration.k8s.io
    - apps
    - autoscaling
    - batch
    - certificates.k8s.io
    - coordination.k8s.io
    - discovery.k8s.io
    - events.k8s.io
    - flowcontrol.apiserver.k8s.io
    - gateway.networking.k8s.io
    - metrics.k8s.io
    - networking.k8s.io
    - node.k8s.io
    - policy
    - rbac.authorization.k8s.io
    - scheduling.k8s.io
    - snapshot.storage.k8s.io
    - storage.k8s.io
    # Common Add-ons
    - acme.cert-manager.io
    - argoproj.io
    - cert-manager.io
    - external-secrets.io
    - fluxcd.io
    - networking.istio.io
    - keda.sh
    - secrets-store.csi.x-k8s.io
    - traefik.io
    - hub.traefik.io
    # GKE / Google Cloud
    - auto.gke.io
    - cloud.google.com
    - datalayer.gke.io
    - hub.gke.io
    - internal.autoscaling.gke.io
    - monitoring.googleapis.com
    - networking.gke.io
    - node.gke.io
    - nodemanagement.gke.io
    - security.cloud.google.com
    - warden.gke.io
    # AWS EKS
    - appmesh.k8s.aws
    - ebs.csi.aws.com
    - elbv2.k8s.aws
    - karpenter.k8s.aws
    - karpenter.sh
    # Azure AKS
    - aadpodidentity.k8s.io
    - appgw.ingress.k8s.io
    - serviceoperator.azure.com
    resources: ["*"]
  - verbs: ["get", "list", "watch"]
    apiGroups: [""]
    resources:
    - bindings
    - configmaps
    - endpoints
    - events
    - limitranges
    - namespaces
    - namespaces/status
    - nodes
    - nodes/status
    - persistentvolumeclaims
    - persistentvolumeclaims/status
    - persistentvolumes
    - persistentvolumes/status
    - pods
    - pods/log
    - pods/status
    - replicationcontrollers
    - replicationcontrollers/scale
    - replicationcontrollers/status
    - resourcequotas
    - resourcequotas/status
    - serviceaccounts
    - services
    - services/status
EOF

# Bind the ClusterRole to the service account
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cleric-rolebinding
subjects:
  - kind: ServiceAccount
    name: cleric-sa
    namespace: cleric
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cleric-role
EOF

# Create a secret for the long-lived token
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: cleric-sa-token
  namespace: cleric
  annotations:
    kubernetes.io/service-account.name: cleric-sa
type: kubernetes.io/service-account-token
EOF

# Get the cluster's API server address
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'

# Get the long-lived bearer token
kubectl get secret cleric-sa-token -o jsonpath="{.data.token}" --namespace cleric | base64 --decode

# Get the cluster's CA certificate
# Note: if using a proxy, provide the CA certificate for the proxy endpoint instead
kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}'

3

Note down the displayed information

Note down the displayed information for use in the Cleric web app.

Note: The built-in view ClusterRole grants read-only access to most resources but does not allow reading Secrets, Roles, or RoleBindings.

What This Enables

With Kubernetes connected, Cleric can investigate cluster resources, pod issues, and deployments:

Why is pod checkout-service-abc123 crashing?

List all pods with high memory usage in production

What changed in the api-gateway deployment in the last hour?

Show me pods that have restarted more than 5 times today

Check if there are any pending pods or resource quota issues

What events occurred in the production namespace since 2pm?

Cleric analyzes pod logs, events, resource utilization, and configuration to diagnose issues like OOMKills, CrashLoopBackOffs, failed deployments, and scaling problems.

Linear

Connect Linear to let Cleric file issues, comment on existing ones, and read your team's backlog during investigations. Cleric appears as a real, non-billable member of your Linear workspace; issues and comments it creates are attributed to Cleric, not to whoever installed the integration.

How it Works

Linear uses an OAuth 2.0 install flow. You authorize the shared Cleric Linear app, choose the workspace to install into, and Cleric receives a workspace-scoped access token plus a refresh token. The access token is rotated automatically; both tokens are stored encrypted in your Cleric instance and can be revoked at any time from Linear's Settings → API → Applications page.

The OAuth grant requests these scopes:

• read: read issues, projects, teams, and comments

• issues:create: create new issues

• comments:create: add comments to issues

Cleric joins your workspace as a non-billable bot member. Linear doesn't count it against your seat count.

Steps to Configure

1

Start the install

In the Cleric Web app, go to Integrations → Linear and click "Connect Linear". You will be redirected to Linear's consent screen.

2

Approve the install

On Linear's consent screen, choose the workspace you want Cleric to install into. Workspace admins approve once; subsequent users do not need to re-consent.

3

Confirmation

When the flow completes, you are redirected back to Cleric and the workspace appears in the Linear integration list.

What This Enables

Cleric can search and read issues, comment on them, and file new issues when responding to investigations. Example uses:

@Cleric File a Linear issue for this OOM incident in the ENG team's backlog

@Cleric What's the status of LIN-1234?

@Cleric Add a comment summarizing this investigation to LIN-1234

Disconnecting

Removing the Linear integration from Cleric's Integrations page immediately cuts Cleric's access to your workspace. The "Cleric" app entry stays in Linear's Settings → API → Applications until a workspace admin removes it there. Doing so isn't required for security (access is already gone), only for tidiness.

MongoDB Atlas

Required Information

• Atlas Project ID (also called Group ID)

• Atlas API public key

• Atlas API private key

How it Works

Cleric connects to the MongoDB Atlas Administration API using HTTP Digest Authentication with an API key pair. During investigations, Cleric can retrieve slow query logs, process-level metrics (CPU, connections, opcounters), and database process logs to diagnose performance issues.

To restrict Cleric to operational data only (metrics, slow query logs, process logs) without access to database contents, assign the Project Read Only and Project Observability Viewer roles. Do not assign Project Data Access Read Only or any other data access role.

Tier limitations: Slow query logs require M10+ clusters (not available on M0/M2/M5 free and shared tiers). Metrics and process logs are available on all tiers, though some metrics (WiredTiger tickets, replication lag, query targeting) require M10+.

Steps to Configure

1

Find your Atlas Project ID

1. Log in to MongoDB Atlas

2. Select your project

3. Go to Project Settings (gear icon in the left sidebar)

4. Copy the Project ID (a 24-character hex string)

2

Create an API key

1. In Atlas, go to Organization > Access Manager > API Keys

2. Click Create API Key

3. Set a description (e.g., "Cleric Integration")

4. Assign the Project Read Only and Project Observability Viewer roles. Do not assign Data Access roles. Cleric only needs performance analytics, not access to database contents.

5. Click Next

6. Copy the Public Key and Private Key (the private key is only shown once)

3

Add Cleric's IP to the API key access list

Atlas API keys require an IP access list. Add Cleric's outbound IP address to allow API access:

1. On the API key page, under API Access List, click Add Access List Entry

2. Add Cleric's outbound IP address (check your Cleric instance's network configuration)

3. Click Save

Without this step, all API calls will return 401 regardless of key validity.

4

Add to Cleric

In the Cleric Web app, go to Integrations > MongoDB Atlas > Add connection. Enter your Project ID, public key, and private key, then click Save connection. Cleric will validate the connection before saving.

What This Enables

With MongoDB Atlas connected, Cleric can analyze database performance and cluster health:

Check MongoDB Atlas for slow queries in the last hour

What are the current connection counts and CPU usage on the Atlas cluster?

Show me the MongoDB process logs around the time of the incident

Are there any collection scans or missing indexes causing slow queries?

What's the replication lag on the Atlas cluster secondaries?

Cleric retrieves slow query logs from the Performance Advisor, fetches process-level metrics (connections, CPU, opcounters, WiredTiger cache), and analyzes database logs to identify performance bottlenecks like missing indexes, collection scans, and connection storms.

New Relic

Connect New Relic to let Cleric query logs, metrics, traces, alerts, and entities using NerdGraph (GraphQL) and NRQL.

Prerequisites

• A New Relic account with Full Platform user type

• A User API Key (starts with NRAK-)

• Your Account ID

Steps to Configure

1

Create a User API Key

• Log in to New Relic and navigate to your profile (bottom-left) > API Keys

• Click Create a key, select User as the key type

• Give it a descriptive name (e.g., "Cleric Integration")

• Copy the key immediately. It is only shown once.

2

Find your Account ID

• In the New Relic UI, your Account ID appears in the URL or under Administration > Access Management

3

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations > New Relic

• Click Add connection

• Select your API Endpoint (US or EU)

• Enter your Account ID and User API Key

• Click Save connection to verify access

What This Enables

With New Relic connected, Cleric can query all telemetry data in your account using NRQL via the NerdGraph GraphQL API:

Show me the error rate for the checkout service over the last hour

What alert incidents fired in the last 2 hours?

Show the p95 latency for all services, broken down by transaction name

Find all ERROR logs from the payment service around the time of the incident

Notion

Connect Notion to let Cleric search your runbooks, postmortems, and knowledge-base pages during investigations. Cleric receives read-only access to the pages you explicitly share with the integration.

How it Works

Notion uses an OAuth 2.0 install flow. You authorize the shared Cleric Notion app, select which pages to share, and Cleric receives a workspace-scoped access token. The token is stored encrypted in your Cleric instance and can be revoked at any time from Notion's Connections UI.

The integration is configured with the Read content capability only. Cleric cannot create, update, or delete Notion content.

Steps to Configure

1

Start the install

In the Cleric Web app, go to Integrations → Notion and click "Connect Notion". You will be redirected to Notion's consent screen.

2

Approve and choose what to share

On Notion's consent screen, choose the workspace and pick what Cleric should see. You can share an entire teamspace, a top-level page, or individual pages or databases. Anything nested inside what you pick is included automatically. You can change this later (see Sharing more pages later).

3

Confirmation

When the flow completes, you are redirected back to Cleric and the workspace appears in the Notion integration list.

What This Enables

During investigations Cleric can search and read the Notion pages you shared during install (and anything nested inside them). Pages outside that scope are invisible to Cleric. See Sharing more pages later if you want to expand or narrow what Cleric can read. Example uses:

@Cleric Find the runbook for high checkout-service error rates

@Cleric What does the on-call rotation page say about escalation?

Sharing more pages later

All of these steps happen inside Notion. Cleric picks the change up automatically.

Share one specific page. Open the page in Notion, click the ··· menu in the top-right corner, scroll to the Connections section, and pick Cleric. Anything nested inside that page is shared too.

Edit the full list of shared pages. In Notion, go to Settings → Connections → Installed, click Cleric, then under Access click Select pages. From there you can add or remove teamspaces, top-level pages, or individual pages and databases.

Enterprise workspaces

Enterprise Notion admins can restrict which third-party integrations are connectable via the workspace's approved connections list. If "Connect Notion" fails for non-admin users, ask your Notion admin to approve the Cleric integration for your workspace.

Disconnecting

Removing the Notion integration from Cleric's Integrations page immediately cuts Cleric's access to your workspace. Unlike Slack, Notion doesn't let an app remove itself from a workspace. The "Cleric" entry stays in Notion's Settings → Connections until you remove it there yourself. Doing so isn't required for security (access is already gone), only for tidiness.

PagerDuty

Required Information

• PagerDuty API token

• PagerDuty API URL (select your region from the dropdown: US or EU)

Steps to Obtain Credentials

Log in to your PagerDuty account

Navigate to API Access Keys

Navigate to "Integrations" > "API Access Keys" under Developer Tools

Create a new API key

Click "Create New API Key"

Enter a description

Enter a Description to help you identify the key later

Create the key

Click "Create Key"

Copy the API token

Copy the generated API token (Note: This is the only time you'll see the full key)

Add to Cleric

In the Cleric Web app, go to Integrations > PagerDuty > Add connection. Enter your API token and select your API URL from the dropdown:

Region	API URL
US	https://api.pagerduty.com
EU	https://api.eu.pagerduty.com

{% endstep %}
{% endstepper %}

What This Enables

With PagerDuty connected, Cleric can analyze incident context and on-call patterns:

What incidents are currently open in PagerDuty?

Show me details for PagerDuty incident #12345

What services have had the most incidents this week?

How many times has the checkout-service alerting policy triggered today?

Cleric uses PagerDuty data to understand alert patterns, incident frequency, and service health trends, helping identify recurring issues and improve alerting effectiveness.

Prometheus

Required Information

• Prometheus server URL

• Authentication credentials (if enabled)

• Prometheus type (Prometheus, VictoriaMetrics Single, or VictoriaMetrics Cluster)

Steps to Obtain Credentials

1

Ensure you have access

Ensure you have access to a Prometheus server or VictoriaMetrics instance

2

Note down the following information

• Server URL (e.g., "http://prometheus.example.com")

• If basic auth is enabled:

  • Username

  • Password

• Prometheus type:

  • prometheus for standard Prometheus installations

  • victoriametrics_single for single-node VictoriaMetrics

  • victoriametrics_cluster for clustered VictoriaMetrics

What This Enables

With Prometheus connected, Cleric can query metrics and alert rules:

Query Prometheus for CPU usage spikes in the last 2 hours

What's the P95 API response time trend since midnight?

Show me all firing Prometheus alerts

Compare current memory usage to baseline from last week

What metrics show anomalies correlated with the API latency increase?

Cleric uses Prometheus to analyze resource utilization, application performance, and alert states, helping identify trends and correlations that explain production issues.

Sentry

Required Information

• Deployment: Cloud or Self-hosted

• Base URL: Required only for Self-hosted deployments

• Organization Slug

• Optional Project Slug

• Sentry personal API token with these scopes:

  • alerts:read

  • event:read

  • org:read

  • project:read

These scopes cover organization validation during setup plus project, issue, alert, and event investigation after the toolkit is connected. Cleric validates the token scopes during setup and rejects tokens that are missing any of these scopes or include additional scopes.

Steps to Configure

1

Create a read-only API token

• In Sentry, open Settings > Account > API > Auth Tokens

• Create a personal token with these scopes:

  • alerts:read

  • event:read

  • org:read

  • project:read

• Copy the token value for the Cleric integration form

2

Find your organization slug and optional default project slug

• Open the target project in Sentry

• Copy the organization slug from the URL

• Optionally copy a project slug if you want Cleric to default to one project during investigations

• If you use self-hosted Sentry, also copy the base URL of your instance

3

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations > Sentry

• Click Add connection

• Select Cloud or Self-hosted. For Self-hosted, enter the Base URL, then enter the Organization Slug, optional Project Slug, and API Token.

• Click Save connection to verify access

What This Enables

With Sentry connected, Cleric can inspect issues, events, stack traces, releases, and project-level error patterns through the Sentry CLI.

List the latest unresolved Sentry issues for the checkout project

Show me the stack trace and latest events for Sentry issue 123456789

Check whether this spike started after a new release in Sentry

Slite

Connect Slite to let Cleric search and read runbooks, incident procedures, architecture notes, and other knowledge-base documentation during investigations.

Prerequisites

• A Slite workspace with Public API access

• Permission to create a personal API key under Settings → API

The key must be read-only. In Slite's Create a new key dialog, turn on the Read-only toggle before clicking Confirm. Do not leave this toggle off. Cleric tests that Slite denies write access before accepting the key. Never connect a read & write key.

Permissions

Create a personal Slite API key with these settings:

Setting	Required value	Why
Read-only toggle	Enabled	Slite enforces that the credential cannot call write endpoints
Key owner access	Only the content Cleric should read	Personal keys inherit all note and channel access of the person who created them

Cleric authenticates the key through GET /me. Because Slite does not provide a REST endpoint that reports a key's scope, Cleric also sends a schema-invalid request to the write-scoped notes endpoint. This request cannot create a note. Cleric accepts the key only when Slite explicitly denies write access; write-enabled or ambiguous keys are rejected.

On Enterprise, you may instead use a read-only key owned by a Restricted service account. Service-account keys are not tied to an employee and can be limited to explicitly shared channels and docs.

Supported and Unsupported APIs

Cleric uses the Slite Public API at https://api.slite.com/v1 for:

• Accessible note metadata and workspace browsing through GET /notes

• Full-text note search through GET /search-notes

• Note metadata and Markdown content through GET /notes/{noteId}

• Authenticated workspace identity through GET /me

Cleric does not connect to Slite MCP. During investigations, it does not use Slite Ask, comments, users or groups, knowledge-management reports, connected Agent sources, or any endpoint that creates, edits, moves, verifies, archives, restores, or deletes content. The connection-time permission check described above is the only call to a write-scoped endpoint, and its intentionally invalid payload cannot create content. Notes unavailable to the API key owner are invisible to Cleric.

The Slite Public API rate limit is 120 calls per minute. Cleric honors Retry-After and retries a rate-limited read once.

Steps to Configure

1

Create a personal read-only key

• In Slite, open Settings → API and click Create a new key.

• In the Create a new key dialog, turn on the Read-only toggle, then click Confirm. The toggle must be enabled; do not create the key with it turned off.

• Copy the key when it is shown. Slite displays it only once.

2

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations → Slite.

• Click Add connection and paste the API Key.

• Click Save connection.

• Cleric verifies the key, workspace identity, and denial of write access before accepting the configuration.

What This Enables

With Slite connected, Cleric can bring operational documentation into an investigation:

Find the Slite runbook for checkout latency alerts

What does our database failover procedure say about promoting a replica?

Compare this incident with the verified deployment rollback guide in Slite

If a known note is missing, verify that the person who created the key can open that note. Because personal keys are tied to a user, replace the key if that person leaves the workspace. Enterprise customers can avoid that lifecycle dependency by using a Restricted service account.

Splunk

Required Information

• Splunk management API URL (typically on port 8089)

• Splunk username

• Splunk password

Steps to Configure

1

Identify your Splunk management API URL

The Splunk management API runs on port 8089 by default (e.g., https://splunk.example.com:8089). This is separate from the Splunk Web UI port (8000).

If you're unsure, check your Splunk deployment settings or ask your Splunk administrator.

2

Create a dedicated Splunk user with read-only access

Cleric only needs permission to run searches. We recommend creating a dedicated user with a role scoped to the minimum required access.

Option A: Use the built-in user role

The built-in user role grants search access across all indexes the role can see, with no administrative or write permissions. This is the simplest option if you're comfortable with Cleric searching all default indexes.

1. In Splunk Web, go to Settings > Users and Authentication > Users

2. Click New User

3. Set a username (e.g., "cleric-readonly") and password

4. Assign the user role

5. Click Save

Option B: Create a custom role with restricted index access

If you want to limit which indexes Cleric can search:

1. Go to Settings > Users and Authentication > Roles > New Role

2. Name it (e.g., "cleric-integration")

3. Under Inheritance, select user as the parent role (this inherits basic search capabilities)

4. Under Indexes, select only the indexes you want Cleric to search in both "Indexes searched by default" and "Indexes"

5. Do not grant any additional capabilities beyond what the user role provides

6. Click Save

7. Create a new user (as in Option A) and assign this custom role instead of user

3

Add to Cleric

In the Cleric Web app, go to Integrations > Splunk > Add connection. Enter your management API URL, username, and password, then click Save connection. Cleric will validate the connection before saving.

What This Enables

With Splunk connected, Cleric can search and analyze logs stored in Splunk:

Search Splunk for errors related to the checkout service in the last hour

Show me timeout errors across all indexes since midnight

What are the most common error patterns in the payment-service logs?

Find logs matching "connection refused" for the API gateway

Search Splunk for trace ID abc123 across all services

Cleric constructs Splunk search queries, retrieves matching log events, and correlates findings with other data sources to identify root causes and patterns across your infrastructure.

Unleash

Connect Unleash to let Cleric inspect feature flags, projects, environments, activation strategies, and change history so it can determine whether a feature flag was responsible for, or coincident with, an incident.

Prerequisites

• An Unleash instance (self-hosted or Unleash Cloud) reachable from Cleric

• A read-only token that can call the Admin API. In Unleash, read-only is the role of the identity behind the token, not a setting on the token itself, so the token must belong to a Viewer. Do not create a plain "Admin" API token: that type is full read-write with no read-only option. Instead, on Enterprise create a service account with the Viewer root role and add an API token to it (recommended because it isn't tied to a person who might leave); on Open Source, create a personal API token while signed in as a user whose root role is Viewer.

Required Information

• Deployment: Cloud or Self-hosted

• For Cloud, your Unleash Instance ID from https://<region>.app.unleash-hosted.com/<instance-id>

• For Self-hosted, your Unleash Base URL (for example, https://unleash.example.com) without /api

• An Unleash API token belonging to a Viewer identity (a Viewer service account, or a Viewer user's personal API token). See Prerequisites.

Supported and Unsupported APIs

Cleric reads from the Unleash Admin API (<base-url>/api/admin):

• Projects: GET /api/admin/projects

• Feature flags (with per-environment state and strategies): GET /api/admin/projects/{projectId}/features and .../features/{flagName}

• Environments: GET /api/admin/environments

• Change/event history: GET /api/admin/events (latest 100, or all events for a project via ?project=<id>) and the paginated GET /api/admin/search/events (offset/limit, from/to, project, feature, type)

Cleric is read-only: it never toggles flags, edits strategies, or changes environments, and it does not read the Frontend or Client SDK APIs.

Steps to Configure

1

Create a read-only API token

The token's access is determined by the role of the identity it belongs to, not by a setting on the token. Do not create a plain "Admin" API token. That type is full read-write and offers no read-only option. Create the token against a Viewer identity instead:

• Enterprise (recommended): go to Admin settings > Service accounts, create a service account with the Viewer root role, then add an API token to it. A service account isn't tied to a person, so the token keeps working when team members leave.

• Open Source: sign in as a user whose root role is Viewer, open Profile > Personal API tokens, and create a token (it inherits that user's read-only permissions).

• Copy the token value.

2

Find your instance URL

• Copy the base URL of your Unleash instance from your browser (e.g. https://unleash.example.com). Remove any trailing /api or path.

3

Configure the integration in Cleric

• In the Cleric Web app, navigate to Integrations > Unleash.

• Click Add connection.

• Select Cloud or Self-hosted. For Cloud, select the region and enter the Instance ID. For Self-hosted, enter the Base URL. Then enter the API Token.

• Click Save connection to verify access.

What This Enables

With Unleash connected, Cleric can correlate incidents with feature-flag changes. This includes finding which flags are enabled in the affected environment, what traffic their strategies actually target, and when they last changed.

Was any feature flag toggled in production right before this incident?

Is the checkout-v2 flag enabled in production, and what rollout percentage is it on?

Show me the change history for the new-pricing flag

Which flags changed in the payments project in the last 2 hours?

Cleric reads Unleash through the Admin REST API only. Flag state is reported per environment, and Cleric inspects activation strategies so it distinguishes "enabled for everyone" from "enabled for a slice of traffic".