The expected window

A slow arrival isn't a failure. The window is how long FlowProofs waits before treating a missing finish as a real problem.

Why a window exists at all

Real systems have normal delay built in: a queue, a batch job, a human approval step, an API that takes a few seconds. If FlowProofs flagged every record the instant it hadn't finished yet, almost everything would look broken almost all the time. The window is the honest amount of time a record is allowed to take before its absence actually means something.

How it's set

During onboarding, once real pings have arrived on both sides, FlowProofs looks at how long they actually took to pair up and proposes a window with a safety margin built in. You confirm or adjust it, never configure it blind. You can change it any time from a flow's settings.

The three states a record moves through

  • Still within window: a source ping arrived, no destination ping yet, but less time has passed than the expected window. Shown in a neutral tone, never as a failure. It's simply too early to know.
  • Resolved late: the destination ping eventually arrived, just after the window had passed. Counted as recovered, not as a confirmed failure, since the outcome still happened.
  • Confirmed gap: the window has fully passed with no destination ping at all. This is the one state that actually alerts.

Why this distinction matters

Alerting on every record still within its window would train you to ignore alerts entirely. FlowProofs only ever alerts on confirmed gaps. See gaps vs. completeness and alerts.