The studio that has to answer the phone

The situation

DevSmooth is an independent software studio in Vancouver. It designs and builds the systems that engineering firms, manufacturers and operations teams run their day on - order management, production scheduling, quality and inspection, sales - and ships them on its own platform, Avospect. Crucially, the studio does not hand over the keys at launch. It runs the systems it builds.

That model puts the studio in an unusual position for a team its size. Each product sits on its own dedicated production host rather than sharing one large machine, which is the right call for blast radius and the wrong call for anyone hoping to keep an eye on things manually. Docker for the application containers, Traefik in front, PostgreSQL underneath, Ansible describing all of it. Deliberately dull infrastructure - and a lot of separate places for something to go quietly wrong at 3am while every client assumes somebody is watching.

Why noise was the actual problem

The hard part of monitoring a fleet like this was never collection. Any agent can collect. The hard part is that on a host running real deploys, the interesting events and the boring ones are structurally identical. A package upgrade touching four hundred files looks exactly like something rummaging through the filesystem. A backup process reading a database looks exactly like exfiltration. A deploy restarting containers looks exactly like a service crash-looping.

Alert on all of it and the notifications become wallpaper inside a fortnight - people filter them into a folder they stop opening, and the one that mattered scrolls past at 3am with the other four hundred. Alert on almost none of it and you are back to finding out from a client. For a studio whose entire promise is "we will know before you do", neither failure mode is survivable.

What they run

Every production host in the Avospect fleet runs the AlertKick agent, observing process execution, file writes, network connections and SSH sessions at the kernel through eBPF. Alongside that, seven external checks hit the public endpoints from outside the network the way a customer would - DNS, TCP, TLS handshake, then the actual HTTP response - with certificate expiry tracked on the same schedule.

Between collection and notification sits AI triage, which reads each event in context and decides whether it is a deploy behaving like a deploy or something that warrants interrupting a human being. What survives goes to an escalation policy with a named owner and a timeout, so an unacknowledged alert climbs rather than sits.

The result

Since May 2026, the agents on the DevSmooth fleet have recorded 89,959 security events. Twenty-seven of them became an alert that reached a person. That is roughly one interruption per 3,300 observed events, and it is the whole argument for putting triage between collection and notification: the value was never in gathering the events, it was in confidently discarding the 99.97 per cent that were infrastructure doing its job.

The practical effect is that alerts from the platform are still worth reading. Twenty-seven in roughly three months is a number a small team can actually take seriously, one at a time, which is the only state in which an alerting system does anything at all.

"We run the systems we build, so an alert at 3am is our problem, not somebody else's. What we needed was not more visibility - it was fewer, better interruptions. Twenty-seven alerts in three months from ninety thousand events is the difference between a team that reads its notifications and a team that has learned to ignore them."

In their words

DevSmooth have written up the same setup from their own side, including the layers they run and the limits they are honest about: how we monitor the systems we run.