The one-person IT team doesn't need more dashboards. It needs the logs to point at the problem.
Most schools we work with have one person looking after IT, sometimes two. That person also handles the Chromebook carts, the projector in room 12, the new starter's account and the printer that only fails during exams. Their network, servers and cloud services are writing thousands of log lines an hour, and almost nobody reads them.
That's not a discipline problem. Logs scattered across switches, firewalls, Wi-Fi controllers, storage and servers can't be read by one person in a normal working day. So small faults run for days or weeks until they turn into a phone call.
We've been building a way to change that for our school clients. It doesn't add another screen to watch. It pulls the logs into one place, makes them searchable in seconds, and turns what they show into something a small team can act on.
The approach has four parts.
A collector on site. Each school gets a small collector inside its network. Switches, firewalls, Wi-Fi controllers, storage and servers send their logs to it, not to some distant service. If the link to our cloud drops, the collector holds the logs and sends them on when it comes back. We tested this during a real connection outage, and nothing was lost.
A central log store in our cloud. Logs are kept and indexed in a dedicated server we run, built on open-source components (rsyslog, VictoriaLogs and Grafana). It's fast enough to search a day of a whole school's logs in about the time it takes to type the question. Raw copies are kept as plain files, so the school is never locked into a format only we can read.
Configuration as code. Every device and server is set up to send its logs through automation (Ansible), not by hand. A new switch or server joins the same way every time, and we can prove what each device is set to do. When something changes, it's recorded.
Privacy by design. We collect what's needed to keep systems running: device events, errors, security events and service health. Client traffic, browsing history and file transfers are deliberately not logged. Schools hold sensitive data about children, and this was a decision we made at the start, not something added afterwards.
A few examples from our first weeks running it at a K-12 school:
A computer silently dropping off the network every nine minutes. The switch logs showed one port going down and coming back more than 170 times in a day. Nobody had reported it. Possibly the person using it just thought the internet was a bit slow. Because the timing was exact, to the second, we could rule out a bad cable within minutes and focus on the device. We also confirmed that the port's protections were stopping the problem spreading to the rest of the network. The outcome was a short, plain-language ticket for whoever was on site: which room, which machine, and one test to run. The diagnosis took an evening, remotely, and nobody had to walk the building first.
A security update that quietly broke a management console. An automatic security update to a reverse proxy changed how it handled one kind of web response. The Wi-Fi management console behind it stopped loading through the proxy, but still worked when accessed directly. The proxy's own logs named the exact type of error, which pointed straight at the update instead of at the console or the network. We rolled back that one package, held it at the working version, and kept a record so it can be revisited when a fixed version ships.
Services that were failing their health checks. The proxies in front of the school's web services log every failed health check. Two backend services showed up as repeatedly unhealthy. Users hadn't noticed yet. Now they're on the list to fix before they do.
Devices with the wrong clock or the wrong name. Several switches and access points were sending local time labelled as UTC, and several servers were reporting old or default hostnames. Each one is a small thing. Together, they make it hard to piece together what happened during an incident, and they would have gone unnoticed without everything landing in one place.
None of these were dramatic. That's the point. Most school IT failures aren't outages. They're small faults that waste time for teachers and students every day, and they're invisible until someone goes looking.
Finding a fault only helps if a small team can do something about it. We build every finding the same way:
We test before we call something fixed. For the computer above, we changed one setting, watched the next two cycles, saw it made no difference, and put the setting back. That's slower than guessing, but it means the ticket says what's actually true.
The next phase is alerting. Today, the logs are collected, searchable and reviewed. Next, the patterns we've found by hand become notifications by email and messaging for the events that matter: a port that won't stop dropping, a firewall rejecting traffic it should allow, a service failing its health checks, a backup that didn't run. We're deliberately bringing every source online before turning alerts on, so alerts are based on a complete picture and not on noise.
A large district can afford a security operations team and an enterprise logging platform. A single school with one IT person can't, but it has the same switches, firewalls and cloud services, and the same faults. What it needs isn't more data. It needs someone, or something, to read the data and tell it what to do next.
That's what we're building: the logs from every system in one place, faults found before they're reported, and each one turned into a clear, small, reversible action that one person can take.
Media78 LLC provides outsourced IT and infrastructure services to K-12 schools.
Book a 30-minute call. We'll talk through what your logs would show
— and whether it's worth acting on.