---
title: Record what a scheduled run finds
description: Have a scheduled AI run raise each problem it finds in tzTrack under a stable key, so a rerun joins the same issue.
slug: /guides/record-what-a-scheduled-run-finds
order: 4
visibility: public
redirects_from: []
---

# Record what a scheduled run finds

Prompt:

> Every night, check the backups and tell me about anything wrong.

Also works: "Run the link check each morning and keep track of what breaks." "Watch the disk space on the servers."

## What your tool does

- Reads the open issues with `find` at the start of each run, so it knows what earlier runs found.
- Gives each problem a stable key: the check's name plus the thing checked, never a date or a run number.
- Raises each problem with `raise` under that key, so a rerun that finds the same problem joins the same issue.
- Marks a problem only you can fix as waiting for you, with `wait` and `waiting_for` set to `person`.
- Closes an issue with `close` once a run finds the check passing again, saying which run found it.
- Ends each run with the numbers of the issues it raised.

## Before your AI starts

This section is for your AI coding tool: what it checks and gathers before it begins. You don't need to do these steps yourself.

- The space the run writes to, and the area for its issues, such as `nightly-checks`.
- The open issues of earlier runs, read with `find`.
- The key for each check. Build it from the check's name and the thing checked, such as `backup-age:orders-db`.

## Steps

### 1. Read what earlier runs found

Call `find` for the open issues in the run's area, so a problem already raised is known.

### 2. Run the checks

Run each check. For each problem, build its key from the check's name and the thing checked. Never put a date or a run number in the key.

### 3. Raise each problem under its key

`raise` each problem under its key, kind `bug`, with what the check saw and a suggested resolution. A rerun that finds the same problem joins the same issue as another report.

### 4. Hand on what only your person fixes

When only your person can act, such as renewing a certificate, call `wait` with `waiting_for` set to `person`. The issue stays open until someone acts; nothing closes it on its own.

### 5. Close what passes again

When a check passes for a problem with an open issue, close it with `close`, the outcome `verified`, and the run that found it passing.

## Expected result

Each problem is one issue, however many runs found it, with each run's finding as a report. A `find` answers what is still wrong, and what waits for your person.

## Refusals

This table lists the refusals this task most often meets; [Refusals](/reference/refusals) lists every refusal with its cause and remedy.

| Refusal | Status | Cause | Remedy |
| --- | --- | --- | --- |
| `credential_refused` | 401 | The run's sign-in ended: it expired or was revoked. | Sign in again through the tool the run uses. |
| `rate_limited` | 429 | Too many calls within the minute: into the space, from your account on calls that work no space, or from one address with no valid sign-in. The detail names which. | Wait for the minute to turn, then repeat the call. |

## Related

- [Issues and kinds](/concepts/issues-and-kinds) explains reports and outcomes.
- [Waiting and claims](/concepts/waiting-and-claims) explains waiting for your person.
- [The tools](/reference/the-tools) lists `raise` and `close`.