Skip to content
DevOps AI ToolKit

Research & open data

Original datasets about production DevOps failures, free to cite and free to download. Everything here is computed from data we actually hold, the method is published, and the limitations are stated in the same place as the numbers.

Dataset · v1.0 · CC BY 4.0

DevOps Error Intelligence

We maintain 2,070 structured error guides covering 24 technologies. Classifying every one of them by *why* it fails — rather than by which tool reported it — produces a picture of production failure that, as far as we know, does not exist anywhere else.

Generated September 7, 2026 · median guide length 1,057 words

Nearly half of production failures are networking or permissions

Those two categories account for 44.5% of the corpus between them — more than configuration, resources, dependencies, state and lifecycle combined.

Error guides by failure category
Failure category What it covers Share Guides
networking Connectivity, DNS, timeouts, refused connections, routing. 22.9% 474
permissions Authentication, authorization, RBAC, credentials, certificates. 21.6% 448
configuration Invalid, malformed or missing configuration. 15.7% 325
resources Memory, disk, CPU, quotas and capacity limits. 11.2% 232
dependencies A required image, package, module or file is absent. 7.9% 163
state Locks, conflicts, drift, corruption and version mismatch. 6.9% 143
lifecycle Start, restart, crash, eviction and termination failures. 2.4% 50

A further 235 guides could not be classified from their title and are excluded from this table rather than assigned a category by guesswork.

Each technology fails in its own characteristic way

The aggregate hides the more useful finding. Terraform failures are overwhelmingly configuration; OpenStack failures are overwhelmingly networking; Kubernetes and the cloud providers are dominated by permissions. If you operate one of these, that is where to spend your prevention effort.

Dominant failure category by technology
Technology Guides Dominant failure Share of that tech
linux 192 networking 18.8%
docker 177 networking 26%
kubernetes 148 permissions 28.4%
kafka 105 networking 28.6%
grafana 99 networking 27.3%
terraform 90 configuration 40%
rabbitmq 86 networking 30.2%
openstack 73 networking 47.9%
prometheus 70 networking 28.6%
aws 56 permissions 32.1%
postgres 53 networking 32.1%
mysql 52 uncategorised 21.2%
ansible 51 configuration 25.5%
slack 50 permissions 32%

Method

Every published error guide in this repository is classified by technology and by failure category using the keyword taxonomies in scripts/build-error-intelligence.mjs. Classification runs over the slug, title and description of each guide. First match wins, with more specific technologies ordered before the platforms that contain them.

The classifier is a plain script in this repository: scripts/build-error-intelligence.mjs. Anyone can read the taxonomies and disagree with them.

Limitations — read before citing

  • This describes THIS corpus, not the industry. It reflects which errors we have written about, which is influenced by search demand and by the authors' own experience.
  • Each guide is assigned exactly one technology and one category. Real failures often span several; the single-label choice keeps the counts unambiguous but loses that nuance.
  • Keyword classification is approximate. A guide whose title omits the obvious keyword is classified as "other" or "uncategorised" rather than guessed at.
  • It is a snapshot of a corpus that grows. The generatedAt timestamp is the only date any figure here refers to.

Open dataset

Released under CC BY 4.0. Use it, republish it, build on it — just attribute it.

Download JSON Download CSV

Suggested citation: DevOps AI ToolKit, DevOps Error Intelligence v1.0, September 7, 2026. https://devopsaitoolkit.com/research/

In progress

State of AI in DevOps 2026

An annual report on how infrastructure engineers actually use AI tooling — what they trust it with, what they review by hand, and where it has made things worse.

There is no data here yet, and we are not going to invent any.

The survey has not run. Publishing a "State of" report built on plausible-looking numbers is common and it is fabrication; this page exists so the methodology can be criticised before the data is collected rather than defended afterwards.

Planned methodology

  • · Open, self-selecting survey of practising infrastructure engineers. Self-selection is a real bias and will be reported as one, not buried.
  • · Sample size and completion rate published alongside every figure, so a percentage drawn from 30 responses cannot be read as one drawn from 3,000.
  • · Raw anonymised responses released as an open dataset under the same licence as the one above.
  • · Questions published in advance, here, before the survey opens.
  • · No vendor sponsorship of any question, and no result gated behind an email address.

Question areas

  • · Which tasks AI is used for, split by whether output is reviewed before it reaches production.
  • · Where AI-assisted changes have caused incidents, and what the failure looked like.
  • · Adoption by team size and by regulatory constraint.
  • · What engineers refuse to delegate, and why.

Want to be told when it opens, or to argue with the methodology first? Get in touch — methodology criticism is more useful before the fact than after.

Open source

The tooling behind this site, released so it can be inspected and reused.

  • devops-error-library

    A Markdown knowledge base of production errors plus errlib, a search tool over it. The corpus behind the dataset above.

  • devops-ai-toolkit

    Python CLI, SDK and FastAPI service for AI-assisted DevOps workflows.

  • grafana-dashboards

    100 spec-generated Grafana dashboards, built from declarative specs rather than hand-edited JSON.