Looking for feedback on SysChecks geo monitoring, incidents and status pages
Hey Indie Hackers,
I’m building SysChecks together with a colleague: https://syschecks.com It’s a lightweight external monitoring and incident response tool for small teams, agencies and engineers. The idea is simple: monitor websites, APIs, DNS, SSL certificates, ports and cron jobs from multiple geo locations, then connect alerts with incidents, status pages and on-call workflows. We started working on it because most tools we used were either: - too simple and stopped at “site is down” - or too heavy/expensive when you only need practical external monitoring SysChecks is still in early beta, so there are definitely bugs and rough edges. But the core is already working, and we’re now trying to collect honest feedback from technical people. A few things we’re currently working on: - better geo monitoring - content change detection - private agent trust/security docs - mobile app - incident workflows - AI-assisted triage and incident summaries, but without burning money on AI calls I’d love to hear your thoughts: - Is the value proposition clear? - What feels confusing on the landing page? - Would this be useful for small engineering teams or agencies? - What would you expect before trusting a private monitoring agent? - What feature would make this worth paying for? Any honest feedback would be super helpful.
Thanks, Pawel
On your questions, as a technical outsider: (1) value prop — "lightweight external monitoring + incident response for small teams" is clear and the gap you're pointing at ("too simple vs too heavy/expensive") is real; I'd make that gap the headline rather than a feature list. (2) Landing page confusion — for an early beta, the top should answer: what does it monitor, how fast do I get an alert, what does it cost. (3) Trust question for the private agent: small teams will want to see exactly what data the agent collects and where it's processed, in writing, before they install anything on a client's infra — a "security" page with a plain-language paragraph beats a docs link. (4) The feature that makes it worth paying for is probably the status page + on-call handoff — agencies resell that to clients.
Thanks a lot this is really useful feedback. I think you’re right that the too simple vs too heavy/expensive gap should probably be much more visible in the headline instead of leading with a feature list. The point about the top of the landing page is also fair. We should make the first screen answer more directly:
- what SysChecks monitors
- how quickly users get alerted
- what it costs / what the beta limits are
The private agent trust point is especially valuable. We already designed it to be outbound-only and limited in what it can do, but I agree that this needs a plain-language security page, not just technical docs. Small teams and agencies need to understand exactly what the agent collects, what it does not collect, and where data is processed before installing it anywhere near client infrastructure. The status page + on-call handoff angle is also interesting. We’ve been thinking about agencies as one of the strongest segments, and your point that they can resell that visibility to clients makes a lot of sense. Really appreciate the concrete feedback this gives us a few clear things to improve on the landing page.
The positioning question feels more important than the feature list here. The gap between “too simple” and “too heavy” is compelling, but I’d be curious which type of customer is already feeling that gap most sharply — small engineering teams, agencies, or someone else.
Thanks Aryan,
that’s a really good point. That’s actually one of the main things we’re trying to validate right now. Our current assumption is that the strongest fit is small engineering teams and agencies/freelancers managing multiple client sites or services. They usually need more than a simple uptime monitor geo checks, DNS/SSL/API/cron monitoring, status pages and basic incident workflows but they don’t want the cost and complexity of a full observability platform. For engineering teams, the pain is mostly around understanding what failed, from where, and how to coordinate the incident. For agencies, it’s about monitoring client sites/services, catching SSL/DNS/cron issues early, and having a simple status page/reporting layer for clients. So the positioning we’re leaning toward is: “External monitoring and incident response for small engineering teams and agencies that need more than basic uptime checks, but don’t need a heavy observability platform.
That makes sense. Have you had any early conversations with either group that point more strongly toward one than the other?