Motivation

Not with a business plan. With a monitoring bill, a dashboard defined in something like a thousand lines of JSON, and the particular tiredness of being told a service is down by a tool that cannot tell you anything else about it.

The complaints were specific and they were all the same complaint. Vendor lock-in, so the work you put in is not portable. Cognitive load past what a human can evaluate at three in the morning. Pricing that is either expensive or, worse, unknowable until the invoice arrives. Four months of evenings, November 2023 to February 2024, went into the first attempt at something better.

Statuspage was first — a Go backend written from scratch, part bare metal and part Kubernetes. It ran. It was also chaotic, the frontend was only half-appealing, and nothing about it was mature enough to hand to anyone else.

PageHealth replaced it, still in Go, and felt genuinely promising for a while. Then it met load. It buckled under heavy traffic, it could not detect flapping properly — arguably the one thing a health checker must get right — and it leaked memory despite having a garbage collector whose entire job is to prevent that. It felt buggy because it was buggy.

Two dead codebases is an unusual thing to lead with. It is also the reason the third one is built the way it is: every structural decision in MonOps is a specific answer to something that broke in Go.

The third attempt was a full rewrite rather than a refactor. Zig was seriously considered and ruled out — it reads as Rust without the safety guarantees, and the previous two attempts had already demonstrated that the bugs worth preventing at compile time were exactly the ones costing the most time.

Rust shipped. Heavy features landed one after another instead of stalling on the load and memory problems that killed PageHealth, and one-second uptime monitoring went straight onto the author's own production Kubernetes servers, in real time, where a false negative is a personal problem rather than a support ticket. It has run there ever since. That is the only endorsement offered here.

Years as a DevOps and cloud engineer, inside mid-sized companies and enterprises operating at global scale, is where the actual thesis came from. The recurring sight was organisations spending thousands a month — often far more — on software that screams. Something is wrong. Load is high. A node is unhealthy. Then it stops, and the humans start guessing.

What nobody had was evidence. Why did that process eat the memory. Why did that node go down. What was actually happening in the sixty seconds before the crash, as opposed to what the five-minute average implies was happening. Answering that is not a dashboard problem, it is a data-collection problem, and it has to be decided before the incident rather than after.

So MonOps records instead of sampling: a rolling five-minute window on every machine at one frame per second, held in memory, written to disk the moment risk crosses a floor or a check fails. Three hundred frames with no gaps, plus the process tree responsible — chosen by sustained CPU rather than an instantaneous spike, so a brief burst does not take the blame for a gradual failure. Then it routes the result to the team that owns it, with the evidence already attached.

The second failure is alert fatigue, and it is usually described as a tuning problem. It is not. It is a design decision: the industry default is to page on first failure and let the on-call engineer act as the deduplication layer.

MonOps confirms from a second region before anyone is woken. If the check recovers, the incident closes itself and nobody is paged at all. If it does not, exactly one person is notified — and the policy only climbs to L2 and L3 if that person stays silent. The measure of the escalation engine is how seldom it fires.

Every tool in this category claims prediction. Almost none publish recall or median lead time, which means you are asked to buy confidence in a black box.

The prediction ledger records every call as hit or miss with its lead time, and recomputes recall every 60 seconds on a dashboard you can see. Misses sit next to hits, unedited. It is a deliberately uncomfortable feature, and it is the one worth trusting precisely because it is uncomfortable.

The original plan was free and open source. That is not what happened, and the reason is ordinary: there are bills, a primary job that does not cover them, and no family safety net behind any of it. Charging for this is what allows it to keep being built.

It shows up in the product as a constraint rather than a compromise. Pricing is flat and legible, because the alternative is the unknowable invoice that started this whole thing. Nothing is metered by log volume, so instrumenting the thing that broke is never punished. Downgrading deletes nothing. If the money were coming from somewhere else, the temptation to price like the incumbents would be much harder to resist.

Every logging stack worth naming — OpenSearch and Elasticsearch, Grafana Loki, Graylog — is resource-hungry in a way that feels disproportionate to the job. On small and mid-sized estates the log tier routinely costs more to run than the thing it is observing.

iLog is the answer to that, built in Rust for the same reasons MonOps was: low-footprint agents on each server, log rotation handled, everything collected and aggressively compressed into TimescaleDB under deliberately aggressive retention policies. It is developed in the open at github.com/mati-cloud/iLog.

Full logging inside MonOps is planned, and iLog is how it arrives — as an in-house centralized logging tier rather than a bundled third-party stack. It is not shipped in MonOps yet, so treat it as a stated direction and not a feature you are buying today.

If you need log search across a large estate right now, today, MonOps is not it yet — iLog is the plan and plans are not products. If you need a single vendor with every compliance certification already in hand, the incumbents have a decade of paperwork that MonOps does not.

It is built for operators who run real systems, carry the pager themselves, and would rather sleep — small teams and MSPs where nobody has time to correlate five tools at three in the morning.

You do not have to take any of this on faith. Install the agent on one machine, break it deliberately, and compare what MonOps hands you against whatever you use today.