Skip to main content

​
Overview

Most observability tells you that a service returned errors. It rarely tells you the thing your customer noticed: the work you owed them did not finish on time. Delivery reliability closes that gap. You tell WHAWIT when a unit of work starts, which steps it goes through, and when it is due. WHAWIT assembles those signals into a single record, notices when one goes missing, ranks what keeps breaking, and — where you allow it — retries the failure automatically.

​
What a delivery is

A delivery is one unit of work your business owes a customer, from start to finish. The word is deliberately generic. In practice it is whatever your product promises: Three properties make it different from a request or a span:
  • It spans services and teams. A delivery fails if any step fails, no matter which team owns that step. Your customer does not care where the boundary was.
  • It has a deadline. A delivery that succeeded four hours late is not a success.
  • It is the unit the customer counts. Not requests, not errors — deliveries.
Step names are yours. order, pick, ship — or anything else. WHAWIT does not impose a pipeline; it records the one you describe. See Configure for your business.

​
Why an error rate is not enough

A 99.98% success rate on your API says nothing about whether the 12 payroll runs due at 09:00 actually filed. Aggregate error rates hide three things a delivery view surfaces:
  • Silence. The worst failure emits nothing at all — a job that never ran, a queue that stalled. There is no error to count. A deadline that passes with no result is the only signal that catches it.
  • Business weight. One failed delivery for a large customer and one failed health check are the same line in an error rate. They are not the same event.
  • Who was at fault. A destination that rejected bad credentials is a customer configuration problem; a timeout in your own egress is yours. Both look like “errors” until they are attributed.

​
The on-time signal

Every delivery can carry a deadline, expectedBy. When it resolves, WHAWIT compares the two and records whether it was on time. If a delivery has no deadline — you did not send one and no default is configured — it is simply not tracked for timeliness. Nothing breaks; you just do not get an on-time number for it. When a deadline passes and no result has arrived, WHAWIT marks the delivery missed and raises an incident through the normal incident lifecycle: triage, escalation policy, on-call schedule, and any Jira or OpsGenie sync you already have. A missed delivery is not a separate alerting stack — it is an incident like any other.

​
Without human intervention

The headline metric is the percentage of deliveries that arrived on time with nobody stepping in. A delivery counts toward that numerator when all of the following hold:
  • it succeeded,
  • it was not late, and
  • nobody recovered it by hand — either nothing was needed, or automated recovery handled it.
A delivery a person re-ran at 3am still counts as delivered. It does not count as hands-off. That distinction is the entire point: most teams are already reliable with a human in the loop, and the cost of that human is invisible in a conventional success rate.
WHAWIT reports both numbers side by side — with and without human intervention — because the gap between them is the work that automation can remove.

​
What the number does not include

Two rules keep the metric honest, and both can surprise you the first time:
  • Only production traffic counts. Deliveries tagged test or internal are excluded from every KPI. Load tests cannot inflate your reliability, and a broken staging pipeline cannot deflate it.
  • A day with no traffic has no percentage. It is reported as no data, not as 100%. A quiet weekend should not look like a perfect one, and it should not average into your trend as if it were.

​
Decomposition

The headline number tells you where you are. The decomposition tells you what to do next. WHAWIT breaks the shortfall down by kind of work, by fault attribution, by whether the failure was transient or permanent, and by error signature — each ranked by how many deliveries it cost you. The top row of that table is the highest-value fix available.

​
What you get once deliveries are flowing

Delivery board

Every delivery with its step timeline, what failed and where, on-time status and links to the underlying traces.

Reliability dashboard

The hands-off on-time rate over time against your target, with the decomposition of everything below it.

Failure modes

Recurring error signatures ranked by the deliveries they cost — a prevention backlog rather than a log search.

Judgment queue

The failures automation could not clear, with the agent’s read on each one and the two actions that resolve it: retry or escalate.

​
Next steps

1

Send outcome events

Instrument your pipeline with the SDK or the HTTP endpoint. See Send outcome events.
2

Describe your business

Tell WHAWIT what your units of work are called, which steps they should have, and when they are due. See Configure for your business.
3

Automate the recovery

Register an endpoint WHAWIT can call to re-drive a failed delivery, under a policy you control. See Auto-recovery and failure modes.