Home / Recipes / Notice when coverage stops
Worked queryNotice when coverage stops
/stories in hybrid mode. The parameters matter less
than the reasoning behind them, so that is most of what is below.
The request
GET /stories
?q=<subject>
&mode=hybrid
&from=<now - 24h>
# alert when the count drops below the trailing baseline
# or the baseline and today in one request, keyword-matched
GET /aggregate?q=<subject>&interval=day&metrics=stories&from=<now - 56d>Why these parameters
Most monitoring alerts on the appearance of coverage. The inverse is often more informative: a subject that was being covered daily and suddenly is not usually means something changed, and nothing will ever trigger a presence-based alert.
The obvious approach, and why it loses
The obvious approach is a fixed threshold — alert when a day returns fewer than three stories — and it will page you every weekend. News volume has a weekly cycle, a holiday cycle and a seasonal one, all of which are larger than most of the drops worth noticing. The second instinct, comparing against yesterday, is worse: it turns every Monday into a surge and every Saturday into a collapse. A trailing baseline computed over the same weekday across several weeks removes most of that structure, and it is the minimum viable version of this recipe rather than a refinement of it.
When it returns too much, or too little
Too many alerts means the baseline is too short or too flat. Lengthen it to eight weeks and compute it per weekday; that alone removes most of the noise, and aggregate_news with interval=day returns the eight weeks in one call rather than fifty-six. Too few means the subject is covered thinly enough that daily counts are mostly zeroes and ones, where a proportional drop is meaningless — aggregate to a week before comparing, and accept that the detector will be slow. If the subject has a genuine publication rhythm of its own, such as a quarterly results cycle or a court calendar, the baseline has to know about it or every predictable trough will read as an event. Encode the calendar rather than widening the tolerance until nothing fires.
How you would know it is working
Backfill it. Run the detector over the last year of a subject you know well and list every alert it would have raised, then mark each as something that mattered, something explainable by the calendar, or noise. The ratio you get is the ratio you will get in production, and it is almost always worse than people expect the first time they look. Track two numbers afterwards: how many alerts a human investigated, and how many of those changed anything. If the second number is zero for a quarter, the detector is not earning its interruptions, and the right response is to raise the bar rather than to keep it running quietly ignored.
When this is the wrong tool
Absence has many causes and this recipe cannot distinguish between them. Coverage stops because a subject was resolved, because attention moved elsewhere, because a newsroom lost the reporter who covered it, or because a public holiday emptied the wires — and all four look identical. The false-positive rate is consequently high, and it is highest exactly when you are least able to check, which is at weekends and over holidays. Build a seasonal baseline rather than a flat one, treat every alert as a prompt to look rather than a finding, and never wire this directly to anything that escalates.
Running it for real
Response fields, failure modes, adaptations and scheduling cost: Notice when coverage stops, in the docs.