How do I tell an AI SRE that a cron job that stopped is a known issue with a documented fix?

Tares lets you attach the runbook for a stopped cron job to the entity it describes, using a reference document. A reference document is declarative reference material, not a stream, so Tares always surfaces it when correlating on that entity, whatever the read time window. When the cron job stops, the AI SRE sees the known issue and its documented fix next to the live events.

How it works

A reference source holds documents (json, csv, md or txt) that you tag with the labels of the entity they describe. Each document becomes one always-surfaced event. Unlike event connectors, nothing is polled or pushed. The config is the data, and editing the source re-materializes it.

This fits a stopped cron job well. A job that stops produces silence, so the useful context is often old: a note written weeks ago about why this job stalls and how to restart it. Because a reference document ignores the read window, a runbook does not age out of a 15-minute read. If the AI SRE correlates on the entity that owns the cron job, the runbook comes back in the timeline together with whatever the job last reported.

The labels you put on each document become real Tares labels. You can read on them and trigger on them, so the runbook is found by the same labels your other sources use for that entity. Correlation is label-native, so the source has no entity key.

For the wider picture of how an AI SRE reads and correlates your sources, see AI SRE.

Set it up

1. Pick the labels that identify the entity the cron job belongs to. Use the same label names your other sources already carry, for example service and environment, so the runbook lines up with the live events.

2. Write the runbook as a short md or txt file. Name the symptom (the job stopped), say that it is a known issue, and list the documented fix as numbered steps. Put the exact steps your team uses in the file, because the AI SRE reads the text as written.

3. Add the source in the UI: Sources → Add source → Reference documents. Upload the file, tag it with the entity labels (for example service and environment with your values), and click Create. To add more documents later, re-open the source and use Upload more.

4. Or declare the same thing as a source. This example attaches one markdown runbook to an entity and declares the label names so reads can correlate on them:

- 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 }

Replace the attachment name, content and label values with your cron job’s runbook and its entity. You can also send the same object with POST /api/sources.

5. Check the result. Open the source: Recent events shows one event per document, and Fields shows the labels they carry. Then read the entity the document describes. The runbook comes back in the timeline even when it is older than the read window.

Each attachment takes these fields:

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

The attachments list is the only key the source needs, and each entry is turned into one always-surfaced event. See Reference documents for the full connector page.

What you get

• The AI SRE sees the runbook whenever it correlates on the cron job’s entity, so a stopped job arrives with its known cause and fix attached.
• The document is always surfaced, regardless of the read time window, so an old note is as visible as a new one.
• Each document is one event, so Recent events gives you a quick check that the runbook is in place, and Fields confirms which labels it carries.
• The labels are real Tares labels. You can read on them and trigger on them, the same as labels from your event sources.
• Updating the fix is an edit. Change the source or use Upload more, and Tares re-materializes it. There is no poll interval to wait for.

When something else fits

• If you need Tares to notice that the job stopped, add an event source for the job or its logs and a trigger on it. The reference document supplies the context once something fires, and it does not detect anything on its own.
• If the content is a stream of changing facts rather than fixed guidance, a reference document is the wrong shape. Use the event connector that matches where the data lives.

Related