Did Your Scheduled AI Jobs Actually Deliver?

Four green runs. How many briefs arrived?

Imagine a team expects one exceptions brief in its private ops channel each weekday by 09:00 Paris time. The agreement is simple: post current exceptions, or stay quiet if the source check finishes by nine and records that nothing changed. At 17:00 Friday the lead reviews the week. These are illustrative records, not customer results.

• Monday, delivered on time. One green run. The right channel contains Monday's brief at 08:56, with the current exceptions.
• Tuesday, quiet by agreement. One green run. The dated receipt shows that all required sources were checked by 08:58 and nothing changed. No message was due.
• Wednesday, recovered late. An error at 08:55 and a successful retry. The right channel received Wednesday's brief at 09:18.
• Thursday, delivery unverified. One green run names an output, but the reviewer has no receipt from the intended channel.
• Friday, no start recorded. A brief was due. The reviewer can find neither an attempt nor a receipt in the records available.

Four of five attempts are green. Four of five scheduled briefs have evidence they started. Those two fractions look identical by coincidence: Wednesday appears twice in the attempt log and Friday does not appear at all. Only two of five scheduled outcomes are verified on time. By the Friday cutoff, three of five are verified if you include Wednesday's late delivery.

That does not make the other two confirmed failures. A working link to Thursday's 08:57 post would change its verdict. A timestamped post made at 10:00 would change eventual delivery, not on-time delivery. Neither would tell you what happened on Friday.

Build the list from the schedule, not from the log

Start with a dated copy of the schedule or a roster the job owner approved. Use the scheduler's occurrence ID. If it has none, identify each due item by a stable job ID and the original scheduled instant in UTC, not by the date or the time the attempt actually started. Keep that key on every retry. Record the local deadline and time zone, intended destination and what counts as done. If a holiday was excluded in advance, keep the dated exception and leave that occurrence out. Do not cross Friday off after the fact because there was no run. Without an independent list of what was due, report the runs you saw and leave coverage unknown.

Suppose the same job is due at 09:00 and 15:00 Paris time on a winter Tuesday. Its original scheduled instants are 08:00 UTC and 14:00 UTC. If the morning job retries at 15:02 local time, that attempt still belongs to 08:00 UTC. It cannot fill the afternoon row. A date-only join would hide the very miss you want to find.

For each due item, attach all matching attempts, then look for the outcome where the team expected it. A generated draft is evidence of work; a current, usable brief in the agreed channel is evidence of delivery. A blank search result from a disconnected source is not a verified quiet day. If the agreement is vague, write a runbook for that recurring workflow before grading it.

This is the difference between a heartbeat and a result. Healthchecks documents how a missing ping is detected against a schedule and grace period. That is useful if you need to know a signal is late. It does not establish who received the brief. Google's SRE Workbook recommends defining what counts as a good event and which events belong in the total. For a team depending on a 09:00 brief, use the briefs due, not the attempts logged.

What to put in Friday's Slack recap

To draft a weekly recap in Slack, give Mio, your AI employee, the approved schedule and only the receipts the reviewer is allowed to see. If the scheduler is not connected, supply the dated roster yourself. Ask Mio to draft a private note: "Start a row for each item on the schedule. Match attempts by occurrence ID, or by job ID and its original scheduled time in UTC. Keep retries on that row, even if a later brief is already due. If a receipt has no reliable match, flag it instead of guessing. Which outcomes were on time, which recovered late and which need someone to check the destination?" This is a way to prepare a review from supplied records, not a claim that Mio monitors every scheduler.

For the week above, the useful part of the note is short: Thursday: channel owner, look for the original post and its timestamp. Friday: schedule owner, check whether the job was enabled and whether the attempt log covers that hour. Wednesday: recovered 18 minutes late; no resend needed. Keep source links inside the authorized channel. Don't rerun a job just to find out whether it already sent something.

If the open question is whether an access change broke delivery, use the installer handover check. If you are still deciding whether a new workflow is ready for its first schedule, use acceptance tests with fixed inputs. Neither replaces Friday's question: of the work the team was promised this week, what can someone actually verify?