# Weekly reliability reports, written by Agent0 and sent by Claude

> Source: <https://dash0.com/blog/weekly-reliability-reports-written-by-agent0-and-sent-by-claude>
> Published: 2026-11-04 14:18:23+00:00

Every Monday someone on the team opens Dash0, checks SLOs, scans failed checks, pulls the top error rates and pastes it all into an email for stakeholders. It's the same queries every week, and nobody enjoys it.

We tried handing that job to Agent0. A Claude scheduled task asks Agent0, through the Dash0 MCP server, to write the weekly report. Claude then turns the answer into an HTML email and saves it as a Gmail draft. This post shows how it fits together, what Agent0 wrote on its first run, and what broke when we tested it.

## [How it works](#how-it-works)

Three connectors in Claude do the work:

- **Dash0 MCP server.** Exposes Agent0 as the runTask tool. Agent0 runs the investigation against live telemetry and returns its findings as text. Over MCP it only reads.
- **Gmail.** create_draft saves the email for review. send_message sends it.
- **Scheduled tasks.** Claude runs a stored prompt on a timer, in a fresh session each time.

Each run goes like this:

1. The scheduled task fires, say Monday at 08:45.
2. Claude calls runTask with the dataset and a report prompt.
3. Agent0 queries metrics, traces, checks and open issues, then writes the report.
4. Claude converts the markdown answer to HTML and calls Gmail.
5. The run leaves an Agent0 thread in Dash0, so anyone can open it and see which queries produced each number.

Claude never queries Dash0 directly in this setup. Agent0 decides which queries to run, which is why the report can cover "what happened this week" instead of a fixed list of panels.

## [What Agent0 wrote](#what-agent0-wrote)

We pointed it at our OpenTelemetry Demo dataset and asked for a 7-day report: SLO status, failing synthetic checks, the top 3 services by error rate, and notable incidents. Agent0 answered in under 45 seconds. An excerpt:

| Service | Error rate | Requests | 
|---|---|---|
| adservice | 30.01% | 379,881 | 
| loadgenerator | 3.96% | 771,583 | 
| frontend | 3.38% | 9,758,356 | 

It also reported that no SLOs were defined in the dataset, that all three synthetic checks passed at every sample, and that four issues were still open at the end of the window, three of them critical.

Two things stood out. It separated instrumented services from dependencies that were only seen from the outside, which is the distinction a reader needs and one we hadn't asked for. And it quoted one check as "4783.00% against a 5% threshold", a raw rule value that would confuse anyone outside the team. That line is the reason the setup below starts with drafts.

## [Set it up yourself](#set-it-up-yourself)

You need the Dash0 MCP server and Gmail connected in Claude, and a Dash0 token that can read the dataset you report on.

1. Ask Claude to run listDatasets and note the dataset's technical ID.
2. In a chat, ask Claude to call runTask with that dataset and your report prompt. Edit the prompt until the answer is something you'd send.
3. Still in the chat, have Claude convert the answer to HTML and call create_draft to yourself. Check it in Gmail.
4. Ask Claude to create a scheduled task with the full prompt and a weekly time. Each run starts with no memory, so the prompt has to carry everything.
5. Review the drafts for a few weeks. When they need no edits, change create_draft to send_message.

The prompt we used:

```
1. Using the Dash0 MCP connector, call runTask with dataset "<dataset-id>", timeoutSeconds 45, and this message: "Write a concise weekly reliability report for this dataset covering the last 7 days, for stakeholders. Include: 1) SLO status and remaining error budget for each SLO (if any exist), 2) failing synthetic checks, 3) the top 3 services by error rate with their error rates, 4) notable incidents or regressions. Use specific numbers and time ranges. Keep it under 400 words, with short headed sections. No speculation beyond what the data shows." If runTask returns a thread link instead of an answer, call waitForTask until it finishes.

2. Using the Gmail connector, call create_draft to <stakeholder addresses> with subject "Weekly reliability report: <team>" and an htmlBody that converts Agent0's answer into clean HTML. Include the Agent0 thread link at the end.

3. Finish with a short summary: whether each step succeeded, the Agent0 thread link, the Gmail draft id, and any errors.
```

The last step matters more than it looks. A scheduled run has nobody watching, and the summary is how you find out what happened.

## [What we learned in testing](#what-we-learned-in-testing)

In a chat, the whole flow worked on the first try: Agent0 wrote the report and the Gmail draft landed a few seconds later.

The scheduled run got halfway. It started 11 minutes after its scheduled time, called Agent0, and Agent0 created its report thread. Then the run ended without creating the Gmail draft, and without the summary we'd asked for. We're still working out why. Until we know, treat the email step in scheduled runs as unproven and check your drafts folder after the first few runs.

A few other notes:

- Agent0 picks its own queries, so the wording and emphasis change from week to week. If stakeholders track a fixed number, such as SLO attainment, pull it with getSlo and let Agent0 write the narrative around it.
- The connector runs as whoever owns the task, and the email comes from their Gmail.
- Each run costs Agent0 usage plus a Claude session.

We'll update this post once the scheduled email step is confirmed.