Operations Overview

The Overview page answers a question no other Kraal surface answers: is the follow-up machinery working?

It is not a second work queue. Everything here is evidence about the pipeline; when something needs deciding, the page sends you to Work List.

What it leads with

A single verdict line at the top, stated plainly rather than as a health score. The most common thing it reports is a conversion gap: items fired, but none of them became work anyone picked up. There is no percentage and no green/amber badge, because a grade next to an open problem invites you to read the grade instead of the problem.

Under it, one row of counts — each stating the window it covers. Anything at zero shows as a dash rather than a 0 tile.

Conversion

Three figures for the last 24 hours: how many items fired, how many delivery attempts were made, and how many became work. Alongside them, the all-time context for what is open now — "3 of 11 open items have ever linked to a task" — so a quiet day is not mistaken for a broken pipeline.

If most of what fires never becomes work, the page says so and points at Rules, where per-rule fire counts tell you which rule is responsible.

Delivery by channel

One row per channel, with what each state actually means:

State	What it means
Sent	The provider accepted the message. Not the same as arrival.
Handed off	Kraal wrote the item to an in-app destination. Nobody has necessarily read it.
No sends this window	Nothing needed sending on this channel. For phone alerts this is normal: only urgent items notify.
Not built yet	Items were routed to a channel that does not exist. They went nowhere; reroute them.
N failed	Sends did not go through, with the reason where the provider gave one.

"Handed off" is deliberate. Writing a row to a table is not evidence a person saw it, so Kraal does not claim delivery it cannot prove.

Raw channel identifiers and provider responses sit behind Technical details, so the row itself stays readable.

Oldest open items

The five longest-open items with their age, client, channel and attempt count, plus the median and 95th percentile across everything open.

An item open for a month or more is either work nobody needs or work nobody can do. Both deserve a decision rather than another delivery attempt, so the rows carry Resolve and Snooze rather than a retry.

Scheduled sends

Each recurring send in plain language — "Every weekday at 7:00 AM", "Every 6 hours" — with when it last ran and when it runs next, and which client it belongs to. A paused schedule says paused rather than showing a next run it will not take. The underlying expression is available under Technical details.

The side panels

• By client — open objectives per client; each row opens that client's requests.
• Pipeline health — whether automation is on, whether the scheduler heartbeat is current, queued sends, and when rules and sends last ran. If one part is wrong, the panel names that part instead of averaging it into a score.
• Intake — how much is ready to send, and what is blocked and why.
• Mobile capture — not instrumented yet. The panel says so in one line rather than showing an empty widget.

Freshness and provenance

The footer states when rules were last evaluated and when the last send run happened, flags anything routed to a channel that is not built, and offers Refresh. The Provenance tab names where the numbers come from and repeats the boundary: decisions live in Work List.