I’m a Linux ops engineer working in the DevOps/SRE space. and over the past few months, I’ve been working on a small *website monitoring* side project in my spare time: https://inostop.com/en/

Most of the monitoring and ops tools I’ve built before were used internally within companies. This is my first attempt to turn a relatively complete tool into something publicly usable.

In day-to-day operations, website monitoring usually involves:

- Infrastructure monitoring - Application / API monitoring - Partial CDN monitoring

These are often built on top of tools like Prometheus or Zabbix, combined with log systems (ELK / OpenObserve) and distributed tracing (OpenTelemetry). While powerful, this stack can feel *heavyweight and overkill* when you just want to quickly monitor a website’s availability.

That led me to experiment with a simpler approach:

- Non-intrusive (no code changes required/Sidecar) - Out-of-band probing to estimate website availability - Conservative thresholds to reduce false alarms

So far, the project covers:

- Domain and TLS certificate monitoring, Ping, Telnet checks - Basic alert thresholds and multi-stage alert silencing to reduce alert fatigue

There are still open challenges:

- There’s still room to improve the UX of the Website Monitoring results (backend is written in Go).

- AI currently works only as an analysis layer on collected data, rather than actively performing real network probes

This project is still evolving (I’ve rewritten parts of it more times than I’d like to admit ).

If you’d like to try it out, there’s an early access code *95f40841e4888668c4d5f7e88506075d*, valid for 1 months, mainly for collecting early feedback.

I’d love to hear feedback from the community:

- Does a lightweight, non-intrusive website monitoring approach make sense in practice? - Are there better patterns or architectures worth exploring? - If you’re a QA or test engineer, I’d love to hear your thoughts.