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

Tares lets you attach the crash loops runbook to the entity it affects as a reference document, so an AI SRE sees the documented fix whenever it correlates on that entity. A reference document is declarative reference material, not a stream, so it is always surfaced regardless of the read time window. You write the known issue and its fix in the document and tag it with the labels of the service it describes.

How it works

The reference connector holds documents in json, csv, md or txt format. Each document is attached to an entity by its labels, for example service=tares and environment=production.

• Not a stream. Event connectors produce events that fall out of a read window as time passes. A reference document does not. A runbook does not age out of a 15-minute read.
• Always surfaced. When an agent correlates on the entity the document is tagged with, the document comes back in the timeline, even outside the read window.
• The config is the data. Each attachment carries its own name, format, content and labels. There is no poll interval and no entity key, because correlation is label-native.
• Real labels. The labels you tag each document with become Tares labels you can read and trigger on.
• One event per document. Each attachment is materialized into one always-surfaced event. Editing the source re-materializes it.

This is how you tell an AI SRE that crash loops is a known issue with a fix. You write that statement and the fix steps into the document, and Tares puts the document in front of the agent whenever it looks at the affected entity. For the wider picture of how agents investigate your systems, see AI SRE.

Set it up

1. Write the runbook as a short md or txt file. Name the symptom (crash loops), say it is a known issue, and list the fix steps in order.
2. In Tares, open Sources, choose Add source, then Reference documents.
3. Upload the file. Tares reads it into text.
4. Tag the document with the labels of the entity it describes, for example service=tares and environment=production.
5. Click Create. To add more runbooks later, re-open the source and use Upload more.

You can also declare the source as YAML, or send the same object with POST /api/sources. The labels list declares the label names so reads can correlate on them, and each attachment provides the values:

- name: runbooks
  connector: reference
  config:
    attachments:
      - name: restart.md
        format: md
        content: |
          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 }

For crash loops, give the attachment a name such as the symptom, put the known issue and fix steps in content, and set labels to the service that crash loops.

Each attachment takes these fields:

• name (required): the file name or title.
• content (required): the document’s text.
• format: one of json, csv, md or txt.
• labels: the entity labels.

To 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 document comes back in the timeline, even outside the read window.

What you get

• The crash loops fix is surfaced every time an agent correlates on the labeled entity, whatever time window it reads.
• The known issue and its fix sit next to the live events for the same service, so the agent sees both in one timeline.
• One document is one event, so you can see exactly what the agent is shown in Recent events.
• The labels on the document are real Tares labels. You can read on them and use them in triggers.
• You update the fix by editing the source, which re-materializes the documents. You extend it with Upload more.

When something else fits

• Use an event connector instead when the data is a stream that changes over time, such as logs, metrics or alerts. A reference document is for static material you want always available.
• If you want an agent’s own observations stored rather than a runbook you write, the memory connector holds those, written with the remember tool.
• The full field list and examples are on the reference documents connector page.

Related