Every plugin we've shipped so far started the same way: as a small, personal annoyance with a bigger tool that got loud about a problem that wasn't actually there. Twice, that annoyance turned into a plugin. This is the honest version of that story — no "we identified a market gap" language, just what actually happened.
The first annoyance: a cron checker that couldn't tell quiet from broken
WP-Cron doesn't run on a real system clock. It only fires when something visits your site — a real visitor, a bot, an API request, anything that triggers a normal WordPress page load. That single fact causes most of the confusion around "why isn't my scheduled task running," and it's the reason a lot of cron-monitoring plugins get it wrong.
The tool we were using before Cron Verdict existed treated every gap in cron activity the same way: if it had been more than X hours since the last tick, it reported cron as broken. On a busy site that's a fine approximation. On a quiet site — a staging environment, a niche blog, a site that mostly gets traffic during business hours in one time zone — that same logic produces a false alarm almost every single day. After enough "cron is broken" emails that turned out to mean "nobody visited your site for six hours," we stopped trusting the tool, which defeats the entire point of having a monitor.
The fix isn't complicated once you see the actual problem: watch two signals instead of one. Has WP-Cron run recently at all (the heartbeat), and did each individually scheduled task fire within a reasonable window of when it was actually due (the per-task check)? A quiet site with a healthy heartbeat and every task firing late-but-present is "running late, and that's normal." A site where the heartbeat itself has gone stale despite real visitors is actually broken. Those are two different situations that deserve two different verdicts, not one panic threshold. That distinction is the entire premise of Cron Verdict.
The second annoyance: a broken-link checker that couldn't tell blocked from dead
The second one came from the opposite direction — not a false "everything is fine," but a false "everything is broken." A link checker flagged a page as a dead 404. We opened it in a browser. It loaded fine. We ran the checker again. Still "broken." It turned out the target site's firewall (Cloudflare, in that particular case) was returning a challenge page to the checker's request — the same kind of response it gives any tool that doesn't look like a real browser — and the checker had no way to tell "the firewall is suspicious of me" apart from "the page doesn't exist."
That's not a rare edge case. Cloudflare, Akamai, Incapsula, PerimeterX, DataDome, and Sucuri collectively sit in front of a huge share of the web, and every one of them will occasionally reject an automated request that a real visitor's browser sails through without noticing. A checker that reports every rejected request as "broken" is going to be wrong constantly, on exactly the sites careful enough to run bot protection in the first place — which tend to be the sites people care most about linking to correctly.
So the fix, again, is to stop collapsing two different situations into one label. A real 404 or a domain that no longer resolves is broken. A request rejected by a recognizable firewall fingerprint is "blocked, likely fine" — a completely different, much less alarming thing, and one that deserves a different action (or none at all) than an actually dead link. That's what Link Verdict checks for before it ever calls something broken.
The pattern, if there is one
We didn't set out with a "Snagbane philosophy" and then go look for problems to fit it. It's the other way around: we hit the same kind of bug twice — a tool that couldn't distinguish between two genuinely different situations, and defaulted to the scarier, louder one — and building the fix both times looked the same. Watch more than one signal. Don't report a guess as a fact. Give people a real verdict, not a raw number they have to interpret themselves.
That's the whole idea behind the name "Verdict," and it's why both plugins are free at their core rather than crippled demos: the honest-verdict part of the plugin isn't the upsell. What we charge for in the paid add-ons is depth on top of that — tracing an overdue cron task back to the exact plugin responsible, unlimited tracked links, daily instead of weekly re-checks, alerts the moment something actually breaks. The free tier's job is to never lie to you, full stop.