Hand off to a coding agent

A brief is a Markdown summary of an alert or a resource and its recent history. Send it to a colleague, or paste it into a coding agent such as Claude Code, which can use it to find the cause and propose the fix in your infrastructure code as a pull request. Cloud Viewer only reads: the change reaches production when a person merges it.

Get a brief

The iPhone and Android apps share briefs. The web app cannot.

• Alert detail → Share in the top bar.
• Resource detail → ⋯ menu. If alerts are firing on the resource, they are included and the brief is written as an incident. If not, the brief says so. Recently resolved alerts appear under “Recent alert history (7 days)”.
• Dashboard → tap a fleet row to expand it. The share actions are at the end of the card.
• An uptime check target’s detail screen, for an endpoint watched from outside.
• Dashboard → Active alerts → share icon in the header: a summary of all current alerts.

Each place offers two actions:

• Share brief sends the brief as text or as a .md file through the share sheet.
• Copy for coding agent copies the same brief with a short instruction block in front: where the data comes from, what it covers, and that the monitoring is read-only, so the agent can start from the first paste.

What a brief contains

The alert (state, severity, when it started, the description, how often it fired this week), the resource (status, specs, labels, related resources, agent status), changes in the last 24 hours, metrics, uptime checks, cost context, recent alert history and links. On Pro and Team, if the resource’s log context has loaded on screen, the brief also includes up to 5 recent log lines, masked the same way. A brief only contains what the screen you share it from already showed.

A brief never contains API tokens, session tokens or any Cloud Viewer credentials. To leave out IP addresses as well, for example before you share into a public channel:

iPhone

Turn off Settings → Privacy → Include IPs in shared briefs.

Android

Turn off Settings → Privacy → Include IP addresses in shared briefs.

Your team’s hand-off notes

Team admins can replace the built-in instruction block with the team’s own text in the portal under Agent Hand-off Notes. There is one note each for alert, resource and uptime-check hand-offs, in plain text, up to 2,000 characters. An empty note keeps the built-in text. Everyone’s Copy for coding agent then uses the team’s note.

Use it to tell the agent where the infrastructure repository is, which runbook to read first, and that changes go through a pull request. The uptime-check note is worth writing separately: a checked endpoint is watched from outside and may not be a machine your team can log in to.

The loop

1. You see the issue in Cloud Viewer. An alert fires, an uptime check fails, a job stops reporting, or costs rise.
2. You hand it to the agent. Use Copy for coding agent and paste the brief. With the Claude connector, the agent can also query Cloud Viewer itself.
3. The agent looks for the cause. It reads the brief, asks the connector for metrics, log lines or alert history, and compares them with your infrastructure code.
4. The agent proposes a change as a pull request. It changes the code that defines the server or service, such as an Ansible role, an OpenTofu module or a Kubernetes manifest, on a branch, and opens a pull request that says what it found and what it changed.
5. CI checks the change. Your pipeline runs the plan or dry run (tofu plan, ansible-playbook --check, a server-side dry run of the manifests) and posts the result on the pull request.
6. A person reviews and merges, or asks for changes, or closes the pull request.
7. The merge rolls the change out. Your deployment pipeline or GitOps controller applies the merged code.
8. Cloud Viewer shows the result. The metric returns to normal, the alert resolves, the check turns green. If not, start again at step 2.

An alert target can also send the brief with every alert, for an endpoint that passes alerts to an agent (Pro and Team). That brief is shorter than the app’s: it carries only the alert, the resource, the links and your team’s note. See Alert webhook.

What the agent needs from you

• Access to the repository that describes your infrastructure, with permission to push a branch and open a pull request.
• No production credentials. Give the agent the rights to propose a change, not to deploy one.
• CI that runs a plan or dry run on every pull request.
• Branch protection on the main branch, so only a reviewed pull request can be merged.
• A deployment that starts from the merge, so the merge is the only step that changes production.

Where you stay in charge

• The brief, the connector and the webhook only give the agent information. None of them can change a server, a project or a setting.
• Nothing reaches production until a person merges the pull request, and the plan in CI shows its effect first.

Example: a disk that fills up

A disk alert fires on app-2: the root filesystem is at 91 % and rising.

1. You open the alert and use Copy for coding agent. The brief shows disk usage rising steadily for three days.
2. You paste it into the agent, running in a checkout of your Ansible repository. Your team’s hand-off note says servers are configured by the app role and changes go through pull requests.
3. Through the connector, the agent reads a week of disk metrics: usage grows by about the same amount every day. In the repository it finds that the application writes its own log files to /var/log/app/, and that the app role sets up no log rotation for them.
4. The agent adds a logrotate configuration to the role and opens a pull request that explains the cause. CI runs the playbook in check mode against staging.
5. You read the diff and the check-mode output, and merge.
6. The pipeline applies the role. Disk usage on app-2 drops, and the alert resolves.

Limits

• Agents can be wrong. An agent can misread a metric, pick the wrong cause or propose a change that goes too far. The review and the plan output are how you catch that. Merge only what you would merge from a colleague.
• Keep secrets out of the conversation. The brief carries no credentials; do not paste any into the agent yourself.
• Cloud Viewer sees what it monitors: your Hetzner resources, the servers that run the agent, your uptime checks and your jobs. It does not know your application code or your repository.

Ask Claude about your serversConnect Claude to Cloud Viewer so the agent can look things up itself.

When something needs attentionThe same path from alert to cause, without an agent.