Monitoring links like you monitor uptime
Nobody would run a server without health checks. Most teams run their entire acquisition through links nobody has tested since launch.
9 August 2026 ยท PAD team
Why one-time testing is not enough
Every mechanism involved here is undocumented and controlled by someone else. Escape schemes work until an app update, user agents change without announcements, and stores adjust their redirects.
The iOS 26 Facebook change is the clearest recent example: detection that had worked for years silently started misclassifying traffic, and nothing anywhere reported an error.
What to watch
| Signal | What a change means |
|---|---|
| Arrival rate by source | a platform changed its browser behaviour |
| Manual fallback rate | an automatic escape route stopped working |
| Unknown user agents on iOS | an app stopped identifying itself |
| Campaign tokens missing at the store | a redirect in your chain started stripping them |
How often
Daily is enough for the first two. Nothing about this changes hourly, and the failure mode is gradual: one app version rolls out, the share of affected traffic grows over days.
What normal looks like
Measured on 21,000 taps routed between 3 and 9 August 2026, Instagram needs the manual fallback on a fraction of a percent of taps and Facebook on several percent. Those ratios are stable week to week, which is what makes a deviation meaningful.
Alerting without noise
Alert on a change in ratio rather than on individual failures. A single stuck tap means nothing; the fallback rate doubling on one platform over two days means somebody shipped an update.
The cheap version
If you do not want to build any of this, at minimum re-run the manual phone test after every major iOS release and every few months otherwise. It costs ten minutes and catches the changes that matter.
We track the arrival rate per source for you, so a platform change shows up as a number rather than a mystery.