Queue latency as a product metric

When a fraud alert arrives fourteen minutes late, users do not look fatigued. They look correctly unimpressed. That delay needs an owner with a number, not a ticket titled “look into workers.”

Product teams narrate tap-through. Engineering narrates p95. The gap between “we sent it” in your app database and “APNs accepted it” often belongs to neither slide. In a regional bank case we were allowed to describe, that gap was the whole story.

Marek’s module in the Lab forces a diagram: trigger event, enqueue, worker start, vendor accept, device display. Each arrow gets a timestamp source. If a source is missing, the arrow is drawn in pencil. Pencil arrows are the homework.

Backoff can look like reach

Aggressive retry without jitter can stampede a vendor endpoint and then look, in CRM, like a successful blast. Throughput diagnostics exist so that “we sent more” is not confused with “users received sooner.”

Give latency a product owner

A metric without an owner returns to folklore. We suggest a single named person — often the PM who owns notification types — with a weekly p95 from trigger to accept. Engineering still builds the worker. Product still has to care when the number moves.

When not to obsess

Promotional recaps that are fine arriving within an hour do not need fraud-alert discipline. Apply latency SLOs to message types that decay. The Grid Method’s queue layer is empty on purpose for campaigns where delay is commercially irrelevant — see the Method page.

If this is your only problem, a private Queue Throughput Diagnostics room may be enough. You do not need twelve weeks of token health to learn that the worker is late.