Google App Links verification has 404ed on /.well-known/assetlinks.json 1285 times across 91 consecutive days
Found while triaging an unrelated scanner sweep, by censusing page_not_found rather than reading the alert rail. Measured on pluto appEvents: route='/.well-known/assetlinks.json', action='page_not_found', 1285 rows from 2026-07-04 03:48:46Z to 2026-10-02 10:04:46Z, 91 distinct days - every day since it started - across 87 distinct IPs. The user agent is GoogleAssociationService on 1284 of them (the remaining one is a curl/8.14.1, someone's manual probe). detail.alert is false on every row, so this has never paged anybody; it is invisible to the zero-noise baseline and only shows up in a DB census. GoogleAssociationService fetches this file because SOMETHING declares a Digital Asset Links association with evolutiva.pensanta.com. That is the question I cannot answer and you can: does Evolutiva have an Android app, a TWA, a Play listing or a Chrome credential-sharing declaration naming this domain? If YES, this is a broken feature rather than noise - app-link verification has been failing continuously since July, which means deep links open in the browser instead of the app and any Play-side verified-links state is failing. The fix is serving a correct assetlinks.json with the real package name and signing-cert fingerprints, which only whoever owns the app can supply. If NO, it is 14 requests a day of pure noise against a file we have no reason to serve, and the close is whichever you prefer: serve a minimal valid empty-array document, or add the path to the suppression set so it stops accumulating rows. Do not simply suppress it before answering the first question - suppressing a broken verification hides the breakage, and on this rail suppression can also mean persist:false, which would delete the evidence. Not urgent and nothing is on fire: zero user reports, zero alerts, and the noise is already silent. It is a 91-day standing 404 that nobody has looked at, which is exactly the class that stays open forever unless someone names it.
Activity
-
CORRECTION to my own rationale on this row, measured 2026-10-04 and it changes what a fix would have to touch. I wrote that detail.alert=false on every assetlinks row is why it never paged. That is not the mechanism. Measured side by side on pluto appEvents: /.well-known/assetlinks.json is 1308 rows with alert=false, tierLevel=info, level=info; /api/app-version is 4 rows with alert=false, tierLevel=warn, level=warn - and the app-version rows DID page me today, one as a real-time warn and two as an explicitly labelled suppressed pair. Both families carry alert=false, so that flag does not gate notification at all; the rail pages on LEVEL. The honest statement for this row is therefore: assetlinks never paged because it is tiered INFO, not because of detail.alert. Two consequences. Anyone trying to make this row louder by flipping alert=true would get nothing. And the suppression mechanism for genuine-noise 404s is already proven in production on this very table - an info tier keeps the row and drops the page, which is exactly the level=info plus persist:true shape agreed in principle on ENAMEL-61 and never built. The gating question for this row is unchanged and still not mine to answer: does Evolutiva have an Android app, TWA or Play listing declaring evolutiva.pensanta.com.
-
DUPLICATE of PLUTO-757, same finding by two independent triage paths three days apart - 757 filed 2026-09-29 off an unrelated single-hit 404, 758 filed 2026-10-02 off a scanner sweep via a page_not_found census. Same route /.well-known/assetlinks.json, same cause (an Android App Links association declared against pluto that has never verified), same non-scanner GoogleAssociationService origin. The counts differ only because they were measured three days apart (1275 vs 1285). 758's MEASUREMENT IS THE BETTER ONE and is folded into 757 rather than discarded: 1285 rows 2026-07-04T03:48:46Z to 2026-10-02T10:04:46Z, 91 DISTINCT days - every single day since it started - across 87 distinct IPs, GoogleAssociationService on 1284 with one curl/8.14.1 manual probe. detail.alert is false on every row, so it has never paged anyone and is invisible to the zero-noise baseline; it surfaces only in a DB census. Keeping 757 rather than 758 because it is the earlier ref and already carries the dependency context. That two lanes found this independently is a signal about the DETECTOR, not about the row: a 404 family that is the largest pluto has, running daily for three months, reached nobody through the alert rail twice over. Recorded on 757 as the thing worth fixing alongside the association itself.