Skip to main content
Golux Group

Server Inspector: Monitoring That Does Not Cry Wolf

Server Inspector: Monitoring That Does Not Cry Wolf

A monitoring SaaS built on the premise that an alerting system is judged by its false positives, because the first noisy week is the week people mute it.

Open the live product
  • Backend
  • Application
  • Business
Location
Belgrade, Europe
Team
Golux Group
Project type
SaaS · Platform
Year
2026

Business challenge

Small teams usually learn their site is down from a customer. The tools that would have told them first are priced and configured for organizations with a dedicated operations function, so the alternative is a free checker that pings the homepage every five minutes. That misses the failure that actually costs money: a page that returns a clean 200 while checkout silently stopped working. And the moment a monitor fires twice on something that was fine, it gets muted, which is worse than having none.

What we did

Checks run every minute across HTTP endpoints, TCP ports and REST APIs, validating status codes, JSON responses and response time rather than reachability alone. Keyword monitoring watches for text that is supposed to be on the page, so a checkout that stops printing "Payment successful" raises an alert even though the server is happily serving. The alerting layer is where the engineering went: an alert is confirmed before it fires, alerts are grouped by application instead of arriving one per check, and a recovery is never reported unless the service actually recovered. An assistant sits on top of the history and answers why something was slow, correlating a latency spike with the deployment that preceded it.

What shipped

  • Uptime, response time, SSL expiry, domain expiry, DNS, redirects and security headers scored out of 100 from a single check
  • One-minute checks on paid plans, with alerts to email, Slack, Discord, Telegram or a signed webhook
  • Branded public status pages, so customers check a page instead of opening a ticket
  • A free tier that permits commercial use, with paid plans at $10 and $29 a month billed through Paddle as merchant of record
  • Built, deployed and operated by us in production, not handed over at launch

How we built it

It began with a question written at the top of an empty page: what makes someone switch a monitor off? Not what makes them buy one. Every competitor was already answering that. The thing that decides whether a monitoring product is still running in six months is whether it has ever lied to you, and almost nobody designs for it.

So the first week went into the alerting model rather than the checks. Checks are the easy half. The hard half is deciding what counts as confirmed, what counts as the same incident, and what counts as recovered. We wrote those rules down before writing the code, because getting them wrong is not a bug you notice, it is a product people quietly abandon.

Then the spine: one scheduler, one check runner, one notification path, with the storage model fixed early because history is the thing you cannot backfill. A monitoring product with a weak history model is a product that can never answer why was it slow last Tuesday, and that is the question that makes the tool feel worth paying for.

After that it widened on purpose and in order. HTTP with status code validation, then response timing, then keyword matching for the silent failures, then TCP and ports, then REST endpoints with JSON validation. Certificates, domain expiry, DNS and headers came next, because those are the outages that embarrass a small company and they are entirely preventable with a calendar nobody keeps.

AI sat in the work throughout, used the way we use it on client projects: to move faster through the parts that are known, to draft and then be corrected, and to argue with a decision before it got made. It did not design the alerting model. It made it possible for one person to get a product of this size into production without the quality dropping, which is a different and more honest claim.

The method, in order

  1. Name the failure that kills the product

    Before any code, we identified the one failure mode that ends the relationship. Here it was false alerts. Everything downstream was then measured against it, which is what keeps a build from drifting into a feature list.

  2. Fix the data model while it is still cheap

    History and incident grouping were decided first, because they are the two things you cannot retrofit. A week spent here is a rewrite avoided later, every time.

  3. Build the narrowest thing that is genuinely useful

    One check type, end to end, from scheduler to delivered email. A working spine is worth more than five half built subsystems, and it tells you immediately whether the model holds.

  4. Widen in order of real risk

    Keyword checks before fancier protocols, because a checkout that silently stops working costs more than a port that closes. Sequence is a product decision, not a backlog.

  5. Operate it, then keep operating it

    We run it in production ourselves and respond to what it does. The last ten percent of a monitoring product only shows up once it is live and someone is depending on it.

Built with

  • Node.js
  • TypeScript
  • PostgreSQL
  • Docker
  • Paddle

For your product

What we would do on your product

The same sequence, starting with the question nobody has written down yet: what is the failure that would make your customers leave quietly rather than complain? We find that first, fix the data model while it is still cheap to move, ship the narrowest useful thing, then widen in order of real risk. You see the plan before we start and you see the date move the week it starts moving, not the week before launch.

Run the free auditSee the product we built

Questions people ask

How long did this take?
It is a product we still work on rather than a project with an end date, which is the honest answer. The spine, one check type running end to end in production, came first and early. Everything since has been widening in order of risk.
Was AI used to build it?
Yes, as a tool throughout. It accelerates the known parts, drafts things we then correct, and is useful for arguing against a decision before it is made. The architecture decisions were ours, which is the part that actually determines whether a product survives.
Can you build something like this for us?
Yes. Continuous checks, scheduled evaluation, reliable notification and a history you can query is one of the most common shapes in back end work, and it is usually the part that gets skipped when a product is built quickly.
Would you work this way on an existing codebase?
The sequence is the same, the first step just takes longer. We find the failure that matters, see what the current data model will and will not support, then change the smallest thing that unblocks the rest.

What the work covered

  • Backend development
  • Frontend development
  • Business consulting
See everything we do

More from Server Inspector

Your project

Want an outcome like this one?

Start with a realistic budget and timeline for your own product, or bring the problem straight to the engineer who would work on it.

Calculate project costBook a strategy call

Keep going

Where to go next

The engineering notes

What we find inside AI-built apps.

The findings from the apps we audit, the fixes that worked, and what each one cost, written by the person who did the work. No roundups, no reposts.

A few emails a month. No spam, unsubscribe any time.

Golux Group

Already a client? Golux Club
is where your project lives: tickets, approvals, files, one record.

Open