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

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 · Alerts from your observability platform · Send your first alert
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 · Azure · Google Cloud · Kubernetes · On-premises · Manage connections
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 · 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
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

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 covers both.

What each 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

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.

What the platform can do with each

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

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).
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 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.

Start with your first investigation, then the guide for your platform: AWS, Azure, Google Cloud, Kubernetes, an on-premises server or a private network. Then wire alert sources or your observability platform, add notifications and tickets, and, when you are ready for fixes, write connections. Manage connections is the reference for every connector field, secret rotation and test failure.