# Choose your connection

> Alert source, read connection, write credential, private-network agent or ticket system — what each agent needs, which connector types serve which need, and where to start.

_Concept · Updated 2026-10-17 · Describes release 0.1.164_

Connect the smallest set that answers your question. An alert source opens incidents; a read connection gives the agent evidence; a write credential lets an approved fix run; a private-network agent reaches what the platform cannot; a ticket system keeps your existing process. None of them requires the others, and you can add the next one later.

## Five kinds of connection {#kinds}

| Kind | What it is | What it enables | Set it up |
|---|---|---|---|
| **Alert source** | Your monitoring posts to `https://<your-platform>/webhook/<source>/<workspace-slug>` with the workspace webhook token. Native adapters: `alertmanager`, `cloudwatch-sns`, `azure-monitor`, `grafana`, `datadog`, `dynatrace`, `robusta`; anything else uses `generic`. The platform stores none of your credentials for this. | Incidents open, group and route (L1–L3). The analysis still runs, but with almost no evidence until a read connection exists. | [Alert sources and intake rules](/help/setup-alert-sources.md) · [Alerts from your observability platform](/help/external-observability.md) · [Send your first alert](/help/send-first-alert.md) |
| **Read connection** (**Investigate only**, role `read`) | A read-only credential to one system — a cluster, a cloud account, a metrics or log backend. It becomes a named tool the agents can call. | Evidence for the investigation and the insights chat; on AWS, Azure and Kubernetes, the estate harvest, the platform checks, security-findings sync and change capture. | [AWS](/help/setup-aws.md) · [Azure](/help/setup-azure.md) · [Google Cloud](/help/setup-gcp.md) · [Kubernetes](/help/setup-kubernetes.md) · [On-premises](/help/setup-on-prem.md) · [Manage connections](/help/manage-connections.md) |
| **Write credential** (**Approved changes only**, role `write`, or a shared `read_write` connection) | A separate identity scoped to the fixes you intend. It is excluded from every investigation registry and does nothing until **Allow use for approved plans** is on. | An approved change executes through it: a pull request on a GitHub, GitLab, Azure DevOps or Gitea repository, or a cloud API, kubectl, CLI, MCP or network-device operation, each released by the approvals its tier needs. | [Write connections and approved fixes](/help/setup-write-connections.md) · [Read role vs write role](/help/read-and-write-roles.md#read-role-vs-write-role) |
| **Private-network agent** | A container (Docker or Kubernetes) inside your network, holding a workspace-scoped token, with outbound HTTPS to the platform and no inbound port. | Read connections and estate scans against systems the platform cannot reach. It verifies readable connections, not an execution-only credential. | [Connect a private network](/help/private-access.md) |
| **Ticket system and notifications** | A Jira Cloud, ServiceNow or Azure DevOps connection with a ticket route; outbound targets of kind Teams, Slack, webhook, email, PagerDuty or Opsgenie. | One ticket per incident: filed when it opens, the analysis written back and the ticket closed when it resolves; tickets arriving by webhook (`servicenow`, `jira`, `azure-devops`) are signals too. Notifications on open, escalate and resolve. | [Notifications, paging, on-call and tickets](/help/setup-notifications.md) |

The scanner findings that feed compliance and SecOps are not a sixth kind: Security Hub and Defender for Cloud findings arrive through the AWS or Azure read connection's **Security findings sync** job, or by push to `/webhook/securityhub/…` and `/webhook/defender/…`. [Turn on compliance](/help/setup-compliance.md) covers both.

## What each agent needs {#agent-needs}

The platform grades a workspace's readiness per agent by connector category: a category is covered when an enabled read connection of a matching type exists, and the gap report names the missing ones.

| Agent | Categories it needs | Where the evidence comes from |
|---|---|---|
| Incident & Problem | Alerting, Metrics, Logs, Kubernetes, Cloud providers | the alert source plus the backends it can query |
| Compliance | Kubernetes, Cloud providers, Git & IaC | cloud and cluster configuration, scanner findings, the repositories the estate is declared in |
| Change Mgmt | Git & IaC, Cloud providers | the change ledger, the repositories, the cloud audit trail |
| SecOps | Security findings, Logs | scanner findings and the logs to corroborate them |
| FinOps · Optimise | Cost / FinOps, Metrics | billing APIs and utilisation metrics |
| Continuous Improve | none | the platform's own data: closed incidents, decisions, corrections |
| Exec Reporting | none | the platform's own data over the other agents' output |

Two rules decide how much the evidence is worth, whatever you connect. The `service` label on an alert must be the same string as the service in the harvested inventory — attribution is an exact match, so `payments`, `payments-api` and `Payments API` are three different services. And every alert should carry `service`, `alertname`, `severity` and a stable identity, with a `resolved` following each `firing`; an incident whose source never sends the clear stays open until an agent verifies the condition or a person resolves it.

## Connector types by category {#catalog}

The catalog groups its types by what they are for; one type can serve several categories. Grafana is an umbrella: one connection also reaches the metrics, logs and traces backends behind it.

| Category | Connector types |
|---|---|
| Alerting | Alertmanager, Datadog, Dynatrace, Grafana, PagerDuty, Opsgenie, Zabbix |
| Metrics | Prometheus, Grafana, Datadog, Dynatrace, New Relic, VictoriaMetrics, AWS, Azure, Google Cloud |
| Logs | Loki, Grafana, Elasticsearch / OpenSearch, Splunk, Log Analytics workspace (KQL), AWS, Datadog, Dynatrace |
| Tracing | Jaeger, Grafana Tempo, Grafana, AWS, Dynatrace |
| Dashboards | Grafana |
| Kubernetes | Kubernetes (MCP), Kubernetes (kubectl + kubeconfig) |
| Cloud providers | AWS, Azure, Google Cloud |
| Git & IaC | GitHub, GitLab, Azure DevOps (Repos, Boards), Gitea, Argo CD |
| ITSM / tickets | Jira, ServiceNow |
| Databases | PostgreSQL |
| Messaging / queues | RabbitMQ |
| On-prem / network | SSH (remote host, read-only), Network device (Cisco / pfSense via netmiko) |
| Security findings | AWS, Azure, Google Cloud, Log Analytics workspace (KQL), Elasticsearch / OpenSearch |
| Cost / FinOps | AWS, Azure, Google Cloud, Kubecost |
| Custom & generic | Generic API connector, Generic MCP connector, Generic CLI connector |

Every type has a declared read surface; a write through an investigation tool is refused whatever the credential allows. The exact rules per type are in [The read/write gate in detail](/help/read-and-write-roles.md#the-read-write-gate-in-detail).

## What the platform can do with each {#capabilities}

| You have | Investigate | Fix | Verify | Compliance |
|---|---|---|---|---|
| An alert source only | Incidents open, group and route; the analysis runs on the alert's own labels and annotations | No: a fix needs a write credential | The source's `resolved` closes the incident; a fix cannot be verified without a connection that sees the target | No |
| Read connections | Evidence from every connected backend; the estate harvest, map and blast radius on AWS, Azure and Kubernetes | No: the agent proposes, nothing executes | Code and, as a last resort, the agent read the target through the connection; a target no connection can see gets `UNCERTAIN — cannot verify` | Platform checks and scanner findings on AWS and Azure, change capture, the controls the agent can evidence |
| A write credential as well | Unchanged: the write role is invisible to the agents | An approved change runs through it, with its rollback drafted first; a certified runbook may run without a per-incident click | Every fix is validated after it runs, and a verdict of *still present* reopens the incident | A failing control becomes a change request that runs the same way |
| A private-network agent | The same, for the systems only the agent can reach | The same, through a write credential the agent holds | The same | The same |
| A ticket system | The ticket is filed, updated with the analysis and closed with the incident | — | — | — |

## Decide in one minute {#decide}

- **Only CloudWatch alarms.** Subscribe the alarm's SNS topic to `/webhook/cloudwatch-sns/<workspace-slug>/<webhook-token>` — SNS cannot set a header, so the token goes in the URL — and connect the account as **Investigate only** so the agent has evidence. No alarms yet: [Built-in detection (AWS)](/help/builtin-detection.md).
- **Prometheus, Alertmanager and Grafana.** Point Alertmanager's receiver at `/webhook/alertmanager/…` with `send_resolved: true`, then connect Grafana (a Viewer token reaches the backends behind it) or Prometheus and Loki directly.
- **Datadog or Dynatrace.** Keep them as the detector: their webhook carries the alert, and a read connection of the same type gives the agent their metrics and logs. [Alerts from your observability platform](/help/external-observability.md) has the paste-in templates.
- **Azure.** An action group webhook to `/webhook/azure-monitor/…` plus an Azure read connection with Reader; Defender for Cloud findings arrive through the same connection's security-findings sync.
- **Kubernetes without a cloud account.** A namespace reader's kubeconfig as a `kubectl` connection; on EKS, `k8s_audit: true` on the AWS connection captures who changed the cluster.
- **Servers or devices the platform cannot reach.** Install the private-network agent first, then connect SSH hosts and network devices through it.
- **You want fixes to run.** Add a separate write credential scoped to the intended operations, switch on **Allow use for approved plans**, and rehearse one approved fix before trusting it with production. A Git repository connection makes the fix a pull request.
- **You want your ticket queue to stay the system of record.** Connect Jira, ServiceNow or Azure DevOps and save its ticket route; add Teams, Slack, email or a pager for the people who need to hear first.
- **Compliance before any alert.** An AWS or Azure read connection with **Security findings sync**, **Platform checks** and **Change capture** ticked, with Security Hub or Defender for Cloud enabled on your side.

## Next {#next}

Start with [your first investigation](/help/getting-started.md), then the guide for your platform: [AWS](/help/setup-aws.md), [Azure](/help/setup-azure.md), [Google Cloud](/help/setup-gcp.md), [Kubernetes](/help/setup-kubernetes.md), [an on-premises server](/help/setup-on-prem.md) or [a private network](/help/private-access.md). Then wire [alert sources](/help/setup-alert-sources.md) or [your observability platform](/help/external-observability.md), add [notifications and tickets](/help/setup-notifications.md), and, when you are ready for fixes, [write connections](/help/setup-write-connections.md). [Manage connections](/help/manage-connections.md) is the reference for every connector field, secret rotation and test failure.


## Next steps

- Next: [Connect AWS](/help/setup-aws.md)
- [All Connect your environment pages](/help/connect-your-environment/llms.txt)
- [Documentation home](/help/)