What data does an AI SRE need to diagnose a cron job that stopped?
Tares gives an AI SRE one timeline per service that merges metrics, logs, alerts and deploy or config changes, so you connect those signals under a shared service label. Deploys are the source to add first, because most real root causes are a change. The agent can only work from the sources you connect.
How it works
Tares ingests each signal as a source. Every source carries the same service label, and that label puts the sources on one timeline for that service. Use one service value for the thing you want diagnosed, here your cron job, on every source you create.
The signal types and the connectors that carry them:
- Metrics: the Prometheus connector, polled on an interval.
- Logs: Docker logs, OpenTelemetry (OTLP) or Vercel logs.
- Alerts: Prometheus alerts or Alertmanager. Prometheus or Alertmanager keeps owning alerting. Tares ingests what fired and correlates it with the evidence.
- Deploys and changes: the GitHub connector, or an inbound webhook source that your CD pipeline posts to.
When an alert lands, a trigger watching those sources fires on a condition you choose. It wakes a built-in Tares agent, or posts the timeline to your own agent service over a webhook. The agent starts with the correlated timeline already in front of it, so it does not spend its first minutes querying each system. It then writes a finding onto the timeline: what broke, since when, the likely cause tied to evidence lines and a next action.
The same timeline is readable from Claude Code, Cursor and any other MCP client, so you can investigate yourself from the same evidence. See Use AI to monitor your systems for the overview.
Set it up
- Install Tares and start it, then start the MCP endpoint in a second shell so a client can read the timeline.
uv tool install tares # or: brew install glassflow/tap/tares
tares up
tares mcp- In the console, go to Sources → Add source and create a source for each signal you have. Use the Prometheus connector for metrics, a log connector for the job’s output, and Prometheus alerts or Alertmanager for alerts. Give every source the same primary
servicelabel, with one value for your cron job. - Add the deploy source first if you add only one. Create a webhook source with a primary
servicelabel read from the payload’sservicefield,event_type: deploy, and a text template likedeploy {commit} by {author}: {message}. Creating it gives you a stable ingest URL. - Add one line to your CD pipeline, run on every deploy:
curl -X POST https://<your-tares>/ingest/<ingest_key> \
-H 'content-type: application/json' \
-d '{"service": "checkout", "commit": "9f2c81d", "author": "dana", "message": "raise db pool size"}'- A second webhook source with
event_type: configcovers config changes the same way. - Create a trigger over those sources, keyed by
service, and choose who it wakes: a Tares agent, your own agent service over a webhook, or a Slack channel.
The full walkthrough, including a demo you can run on a laptop, is in Build an AI SRE.
What you get
- One timeline per service, with metrics, logs, alerts and deploys on one clock.
- A deploy event on the timeline for every POST your pipeline sends, so the agent sees a change landing next to what happened after it.
- A finding written onto the timeline when the agent’s run finishes. The next investigation, yours or another agent’s, starts from that finding instead of from scratch.
- The same evidence for any MCP client you connect.
What the agent reads is what you connected. A signal you leave out is absent from the timeline, and a source without the shared service label is not on it. If a diagnosis feels thin, check which of the four signal types has no source for that service, and add the deploy and config sources first.
When something else fits
- If you want to look at evidence yourself rather than wake an agent, connect an MCP client such as Claude Code and ask it to read the service’s recent timeline.
- If your alerting already lives in Prometheus or Alertmanager, keep it there. Tares ingests what fires and does not re-threshold it.