Google Alerts is the first monitoring tool most journalists ever set up, and the first one they catch failing. The courthouse story your alert was built for breaks at 09:10; the email lands mid-afternoon, if it lands at all. So you nudge the settings to "as-it-happens", and it happens again next week. The instinct is that you configured it wrong. You did not.
Why the delay is structural
Google Alerts is a query saved on top of Google's index. Before it can tell you anything, a chain of things has to happen in order:
- A page is published. The story already exists; the clock has started.
- Google's crawler visits the site. On its schedule, not yours. Big news sites are crawled often; the small, local and specialist sites your beat depends on are crawled far less.
- The page is indexed and deduplicated against everything else Google has seen.
- Your query matches, and the alert is queued for delivery: into a digest, or, on the fastest setting, into an email that means "as it entered the index", not "as it happened".
Every stage adds minutes to hours, and the stages multiply. That is why the delay cannot be tuned away: the product is downstream of a crawl, and a crawl is a polite visitor that comes around when it comes around. There is a recall problem stacked on top: paywalled pages, pages the crawler deprioritises, and anything deduplicated away will never fire your alert at all. Alerts does not promise completeness, and it does not deliver it.
Push versus crawl
The useful mental model has two verbs in it. A crawler asks: it visits a page on a schedule and checks whether something changed. A push tells: the newsroom itself decides "this is worth interrupting people for" and sends that decision to every phone at once, the second they commit. One is polling; the other is the event.
The gap between the two is not marginal. Across a year of push notifications (537,376 alerts from 336 news apps), the median time between the first and the second newsroom pushing the same story is 16 minutes, and under four minutes in Sweden and Norway. The competitive window of a breaking story is often shorter than a single crawl interval. A tool that reports in hours is not late to the story; it is reporting on a different day's news.
| Method | How it learns about news | Typical latency |
|---|---|---|
| Push monitoring | The newsroom's own alert, captured as it is sent | Seconds |
| Website change detection | Re-checks specific pages you chose | Minutes, per page watched |
| RSS reader | Polls feeds the site publishes | Minutes to hours |
| Google Alerts | Crawl, index, match, batch, email | Hours; digests up to a day or more |
What Google Alerts is still good for
This is not a burial. Alerts is free, effortless, and covers the entire indexed web, which no push or feed tool does. Keep it for the jobs where those strengths matter and a day's delay does not:
- Your own name, your outlet, your investigation's subjects: long-tail mentions anywhere on the web.
- Slow-moving research beats, where the question is "did anyone write about this at all", not "who was first".
- Obscure phrases and document titles that only ever appear once, on sites nothing else watches.
The mistake is not using Google Alerts. The mistake is using it as a breaking-news alarm.
What to use instead, by job
| The job | The right tool family | Examples |
|---|---|---|
| Know a story broke, in minutes | Push-notification monitoring: live columns of what newsrooms are sending, filtered by source, country, keyword and cross-source consensus | AO.news (free live demo) |
| Watch specific pages: court lists, agendas, regulator announcements | Change detection with an archive of what changed | Klaxon Cloud (free), Visualping (free journalist plan) |
| Follow niche sites that publish feeds | An RSS reader with keyword rules | Feedly, Inoreader |
| Brand and topic mentions at scale | Social listening, built for reports rather than speed | Brand24, Mention, Meltwater |
| Chatter before it is news | Curated lists on the networks your beat lives on | X lists, Bluesky deck clients |
The push option, in practice
If the job is breaking news, here is what replacing the alert actually looks like in AO.news. You rebuild your Google Alerts query as a word filter on a live column: the same boolean syntax ((energy OR electricity) AND !sport), applied to the English translation of every push, so one query covers 31 languages. You scope it to sources: one country, a hand-picked set of outlets, or everything. And instead of an email digest, the column forwards to a Slack channel the moment each matching notification arrives.
Two things Alerts never gave you come with it. Consensus: AO.news clusters notifications about the same story, so you can require "at least 3 independent newsrooms" before your channel fires, which is a rumour filter no keyword can express. And a timestamped record: every notification has a permalink with source and send time, so "when did this actually break" has an answer.
The honest limits, so you can compare fairly: AO.news watches newsrooms, not the whole web. If nobody pushes a story and no front page carries it, an indexed blog post is something Alerts would eventually find and AO.news would not. That is why the table above is by job: most desks keep Alerts for the long tail and move the breaking-news job to push.
FAQ
Can I make Google Alerts faster?
You can set delivery to "as-it-happens" and sharpen the query, and it will still be bounded by crawl and index time. There is no setting for "before the story is over".
Does AO.news support my Google Alerts query?
The word filters support AND, OR, !, parentheses and quoted phrases, applied to translated text. Most Alerts queries paste across with minor changes.
What does it cost?
The demo deck is free and shows the live stream. Newsroom plans, which unlock full text, Slack and the API, are priced per newsroom: hello@ao.news.