The honest case for building it yourself
A cron job running curl every minute is genuinely useful, costs nothing, and takes twenty minutes to write. If you are monitoring one internal service and the consequence of missing an outage is mild, that is a completely reasonable choice and you should not feel bad about it.
The problems appear at scale and at the edges. You need somewhere reliable to run it that is not the infrastructure being monitored. You need a second location to distinguish a network blip from a real outage. You need alert routing, deduplication, history retention, and certificate parsing. Each piece is straightforward; together they are a product, and it is not the product you are trying to build.
What single-location checking misses
The limitation is not obvious until it bites. One probe location gives you one network path, and that path has its own weather. Transient packet loss between that specific prober and your origin looks exactly like your service failing.
The consequence is false alarms, and the consequence of false alarms is that people stop reading the alerts. In the other direction, a single location cannot see a failure that only affects one continent — a CDN edge serving errors in Asia is invisible to a probe in Virginia, while a real segment of your users cannot load the page.
One probe reporting a failure is a hypothesis. Several independent regions agreeing is an incident. That distinction is what separates monitoring you trust at 3am from monitoring you have learned to swipe away.
When you do not need us
If your project has no users yet, a free single-location checker is completely adequate and you should use one. If you have an existing observability stack with synthetic checking already configured across regions, you have solved this problem.
SutramX is aimed at the middle: teams with something real to lose, who do not want to assemble and maintain a monitoring system to protect it.