Apple quietly stopped answering my server, and only an hourly test caught it
My Mac app directory fills in an app's name, icon and price from a pasted link. It broke twice in one week without a single error, and the fix was a test that pastes a real link every hour, from the same servers my users hit.
The decision or problem
MacPip is a free directory and daily launch site for Mac apps, with a retro 1984 Macintosh look. The most important moment on the site is the submit page. A maker pastes a link to their app, and MacPip reads the name, icon and price so they don't have to type them. If that step feels broken, people leave.
The site runs on Cloudflare. Everything worked on my Mac and every test passed. But the reading happens on Cloudflare's servers, not on my laptop, and that difference turned out to matter a lot.
What happened
One evening an email from my own site said Mac App Store links had stopped filling in. Nothing had changed in my code. From my Mac, Apple's lookup answered fine. From Cloudflare, Apple refused almost every request.
The next morning it was Gumroad's turn. Gumroad also sits behind Cloudflare, and now and then it turns away requests that come from Cloudflare's own servers.
Neither one showed an error a user would see. The form just came back empty, and a maker would think they had to type everything themselves.
What I tried and why
- A test that runs where the users are. Every hour, MacPip reads five real links (a Mac App Store app, a GitHub repo, a Setapp app, a Gumroad product and a plain website) from Cloudflare itself. If the name, icon or price goes missing, I get one email, at most once a day for the same problem, and one more when it works again.
- A second way in for each source. When Apple's lookup refuses, the reader now reads the App Store page itself, which still answers. When Gumroad shows a block page, it tries again and reads the product data another way.
- Keep good results. A good read is kept for a week, so a maker still gets their details on a bad hour. The hourly test always reads fresh, so the saved copy can't hide a real outage.
- Record why it failed. A failed read now notes what each request got back, so the next alert tells me exactly where it broke.
What surprised me
The test passing on my machine meant almost nothing. Apple and Gumroad treat a request from a big shared cloud very differently from one sent from a home internet connection. I also learned that "it worked yesterday" is the normal state right before something breaks.
What another builder can use
If your product reads other sites (link previews, imports, scrapers), test from the same servers your users go through, on a schedule, with real links. Have a second way in for each source, keep the last good result, and make the alert say what came back, not only that it failed.
You can list or launch a Mac app for free at macpip.com.