How do I tell an AI SRE that failed deploys is a known issue with a documented fix?

Tares lets you attach the failed deploys runbook to the affected entity as a reference document, so your AI SRE gets the documented fix whenever it correlates on that entity. A reference document is declarative material, not a stream, so it is always surfaced regardless of the read time window. You write the fix once, tag it with the entity’s labels, and it comes back with every read of that entity.

How it works

The reference connector turns each document you attach into one always-surfaced event. Unlike the event connectors, it is not polled or pushed, and it has no entity key. Correlation is label-native, so the document is matched to an entity by its labels.

• The config is the data. Each attachment carries its own name, format, content and labels.
• Labels tie the fix to the entity. The labels you tag a document with, such as service=tares and environment=production, become real Tares labels you can read and trigger on.
• The time window does not apply. A runbook does not age out of a 15-minute read. When your AI SRE reads the entity, the failed deploys document is in the timeline even if no recent event mentions it.
• Editing re-materializes it. Change the source and Tares rebuilds the documents, so there is no poll interval to manage.

For the wider picture of how an agent investigates and correlates, see AI SRE. The connector itself is described on the reference documents page.

Set it up

1. Write the fix as a short document in json, csv, md or txt. A markdown runbook named for the problem works well, for example the known issue (failed deploys) followed by the steps that fix it.
2. Decide which entity the issue belongs to, and note its labels. The example below uses service=tares and environment=production.
3. In Tares, open Sources → Add source → Reference documents. Upload the file, tag it with those labels, and click Create. To add more runbooks later, re-open the source and use Upload more.
4. Or declare the same thing as YAML. Each attachment provides the label values, and the top-level labels declare the label names so reads can correlate on them:

- name: runbooks
  connector: reference
  config:
    attachments:
      - name: failed-deploys.md
        format: md
        content: |
          Known issue: failed deploys.
          1. kubectl rollout restart deploy/tares
          2. watch the pod come healthy
        labels: { service: tares, environment: production }
    labels:
      - { name: service, field: service }
      - { name: environment, field: environment }

5. If you prefer the API, send POST /api/sources with the same object.
6. Verify. Open the source: Recent events shows one event per document, and Fields shows the labels they carry. Then read the entity the document describes:

read({ service: tares })

The failed deploys document comes back in the timeline, even outside the read window.

Each attachment needs a name and content. The format is one of json, csv, md or txt, and labels holds the entity labels.

What you get

• Your AI SRE sees the documented fix for failed deploys every time it reads the entity, not only when the deploy failure is recent.
• The runbook sits next to the live events for that entity in one timeline, so the agent can match what is happening to what you already know.
• The labels on the document are real Tares labels, so you can read and trigger on them like any other label.
• One place to maintain the fix. Edit the source and the document is re-materialized.

When something else fits

• If you want Tares to react to the failure itself, such as alerting when deploys fail, use a stream connector and a trigger. A reference document only supplies the known fix, it does not detect anything.
• If the knowledge is an observation an agent learned on its own rather than a document you wrote, the memory connector is a better fit than a reference document.

Related