Check Readiness Before a Close

Description

On the days that matter most — month-end, a forecast submission, a board pack — the question is not “what has Weave noticed?” but “are we ready?”. A readiness set names the workflows a deadline depends on, and selecting the set answers that question for all of them at once, in one checklist that opens with its own count:

11 of 13 ready; 1 not ready; 1 couldn’t check.

Each workflow in the set gets one of three answers, the worst of its lines. It is Not ready when any check found a problem; the problem is listed beneath it with the same Fix, Go To and How Weave knows buttons as the Weave tab. Otherwise it is Couldn’t check when any check had no way to judge it, and the reason is written out. It is Ready only when every check Weave could run on it passed. Nothing Weave did not judge is ever shown as ready.

The checks are the rules Weave already runs — no AI is involved — so a checklist costs nothing however often you ask for it. For what those rules read and what their answers mean, see What Weave Checks.

Make a Readiness Set

1. Open the project’s Weave tab and click Readiness in its toolbar.
2. Click New. Give the set a name, such as “Month-end close”, and move the workflows it depends on from Workflows in the project to Workflows in this set.
3. Optionally tick Has a due time and say when the set is due, as a cron expression and the timezone it is written in — the same choices a scheduled event offers. 0 9 5 * * is 09:00 on the 5th of every month, and 0 8 * * 1 is 08:00 every Monday, in that timezone. The offsets are read as a scheduled event reads them: UTC +0 is London time, British Summer Time included, and some other offsets follow the daylight saving of a place at that offset while the rest are fixed. The Event Scheduler page lists what each offset is read as.
4. For a set with a due time, under Tell the owner this many hours before it is due, say how long before the due time Weave should send its message, from 1 to 168 hours. The default is 24.
5. Click Save.

A set belongs to the project and everyone who can open the project’s Weave tab can check it. Only a project Architect can make, edit or delete a set, and every workflow in a set must be in that project. Whoever last saved a set is its owner. Two people editing the same set at once are kept apart: the second save is refused, the set is read again, and the form shows the newer copy with the reason.

Weave can only call an input table fresh when something says when it should have been written: a schedule on the workflow that writes it, or a freshness threshold on the table. Set those first, or the first line of most workflows will read Couldn’t check.

Read the Checklist

Select a set on the left. Weave reads the whole project — the same read the Weave tab makes — and judges each workflow in the set. Click Check Again after you have fixed something.

Each item shows the workflow’s name, its verdict, and one line per check that applies to it. When a line says Couldn’t check, the reason is written out beside it; these are the reasons you are most likely to meet:

Line	What Weave compares	Common reasons it says “couldn’t check”
Inputs are fresh	Every table the workflow reads, against the schedules of the workflows that write it, or the table’s own freshness threshold.	Your role can’t read tables; Weave couldn’t work out which tables it reads, or it reads none Weave can follow; a table it reads is hidden from you; a step reads a table Weave can’t work out, such as one picked with a variable; a table it reads has neither a scheduled writer nor a freshness threshold, so nothing says when it should have been written; the workflow that writes it is running, queued or has only just finished.
Last run succeeded	The workflow’s most recent run, which must have finished. A run that failed is Not ready.	It has no runs on record, its run history couldn’t be read, or its last run was stopped or is still going.
Last run looked usual	How long the last run took, and how many rows its tables held afterwards, how many empty values they held and how their values spread, against the earlier runs.	The last run failed, was stopped or is still going, so there is nothing usual to compare; a step has too few earlier runs; the last run was the first to fill a table it writes, so there is no earlier version to compare; row access applies to a table it wrote, so that table’s values aren’t compared; the run includes steps your role can’t see.
Inputs unchanged since it last ran	Whether a table it reads was written to by another workflow after it last read it.	Your role can’t read tables; Weave can’t follow what the workflow reads; or the workflow has no runs to compare against.
Schedule is healthy	Its scheduled events: valid timetables, in step with the scheduler, no due run missed, no due time lost to a run still going.	The scheduler couldn’t be read.

A workflow with no scheduled events has no Schedule is healthy line, and the item says it is not scheduled. That is a fact about the workflow, not something Weave failed to check.

A workflow that has been deleted from the project since the set was made, or that your role can’t see, is still counted. It appears as Couldn’t check with the reason, so the count never quietly shrinks.

Note

Ready means every check Weave could run passed. It is not a statement that the workflow’s figures are right, that its dashboards are current, or that anything outside the project is in order. The lines name exactly what was compared, and How Weave knows on a finding names what the check leaves out.

Be Told Before the Due Time

For a set with a due time, Weave runs the check on its own as the due time approaches and tells the set’s owner — whoever last saved it — once for each time the set comes due, as an in-app message:

“Month-end close” is due in 3 days (31 Oct 17:00 UTC): 11 of its 13 workflows ready, 1 not ready, 1 Weave couldn’t check.

Click Open Weave on the message to open the project’s Weave tab and the checklist for that set. The message carries counts only; the names and the reasons are in the checklist. It stays on screen for 30 seconds and is shown only if the owner is signed in at the time; it is not sent again for that due time, but the checklist is always there in the window. If the owner can no longer open the project, nothing is sent.

Weave checks once an hour, so the message arrives within an hour of the notice point: with 24 hours’ notice, within an hour of 24 hours before the due time. A set saved after its notice point has passed is told at the next check. The check runs as the owner, and it reads tables only if the owner could read tables when they last saved the set.

Through the API

Readiness sets are available through the platform API under /analyze/weave/readiness: GET /sets lists a project’s sets, GET /set, POST /set, PUT /set and DELETE /set read, create, replace and delete one, and GET /check returns the checklist as the window shows it, with each line’s findings. A set read through the API carries an etag; send it back as if_match on PUT to have an edit over a newer save refused. Without it, the last write wins.