Two Thousand Connectors, and What That Number Actually Counts

Every vendor in this category quotes a connector count and almost none says what it is a count of. Here is ours, broken down, including the part that makes it less impressive.

Connector counts are the least examined number in enterprise software. Everyone publishes one, the numbers are all suspiciously round, and almost nobody says what they are counting. So before ours: it is 2,026, and here is the whole breakdown, including the bits that make it less impressive than the headline.

What is in the catalogue

By role rather than by suite: 1,125 sources, 605 transforms, 296 sinks. Spread across 63 categories and 192 subcategories, the largest being Productivity at 400, then General at 231, AI and LLM at 105, Cloud Storage at 86, Security and Identity at 60, TechOps at 58. Every entry carries documentation. Twenty-one are marked restricted, meaning they cannot be invoked without an explicit grant.

The category names tell you something the total does not. This is not two thousand monitoring integrations. It is a data and orchestration layer that happens to include the monitoring, ITSM and cloud connectors an operations platform needs, sitting alongside a great deal of ingestion and transformation capability that exists because the same layer moves data for other purposes.

The part that makes the number smaller

Nobody hand-writes two thousand integrations. The connector layer is built on a processor framework, which is how any vendor reaches four figures. Some of these entries are framework-standard processors, some are ours.

We would rather say that than let the number imply two thousand bespoke engineering efforts. What is genuinely ours is not the raw count. It is the layer around each entry: the documentation, the category and suite classification, the restriction model, and the governance that decides whether an agent may invoke a given connector as the calling user with attribute-level data filtering. That is the work that turns a processor into something safe to hand to an autonomous system.

The question to ask every vendor, including us

A catalogue count answers "could this connect to my tool." It does not answer "has this connected to my tool, in production, at a named customer, and what broke." Those are extremely different claims and the industry has spent a decade collapsing them into one number.

So the useful question is not how many connectors a vendor has. It is how many are running at a customer you can name, and can I speak to them. Our answer to that is smaller than 2,026 by a wide margin, as is everyone else's, and a vendor who does not visibly flinch at the question is worth a second look.

This is the same discipline we apply to performance figures, set out in how we decide what to publish as a number. A number without a stated denominator is a decoration, and connector counts are the most decorative numbers in the category.

Why the breadth is there at all

An operations platform that only reads monitoring tools cannot answer most incident questions. The interesting correlations run outward: a latency alert explained by a deployment record, a payment failure explained by an identity provider, a batch failure explained by a file that never landed in object storage. Every one of those crosses out of the observability estate into something else.

That is why the catalogue is shaped the way it is, and why Productivity is the largest category rather than TechOps. The signals that explain an incident are frequently not operations signals. We walk one version of that in when Datadog raises a monitor alert: the monitor is accurate about the threshold and the explanation lives in three systems Datadog was never pointed at.

The catalogue is browsable by suite and category on the integrations page. Connectors come with the platform rather than as a separate purchase, and we add new ones based on customer demand.