Earlier quoted context omitted.
That would actually be more stable, since it would rely on a network designed for fault-tolerant redundant store-and-forward messaging. Instead, each cron job runs an HTTP GET, and later you can view the service's website to see the tests that have requested successfully or haven't responded at all. Unfortunately for your system, if there's a network hiccup, you won't know why your jobs failed and the job will hang o…
Unfortunately for your system, if there's a network hiccup, you won't know why your jobs failed and the job will hang on the HTTP call. Also, you're paying for it instead of just sending e-mail alerts to yourself. Critically importantly for this use case, if you are doing something critical for your business (say, backups or your daily billing run or sending reminders to thousands of people or what have you) and some…
If you have intermittent packet loss on your internet connection you get constant alerts about your backups not working, even though it's just the internet that's wonky. Or if this service isn't set up robustly enough, you miss your alerts when they go down. Either way you get no context about the failure, just obscure panic in the middle of the night. On top of that an attacker can enumerate the URLs (or find it via some other means) and send false requests while they take down your service without you noticing, or the opposite effect with a DDoS on the provider.
I'm not saying it's not a useful service. I'm sure plenty of people would rather pay for this thing and have some peace of mind rather than nothing (because most of these users probably aren't technical enough to do something identical in Google App Engine or a VPS). I just have high expectations for solutions that you have to pay for.