What changed, in plain English.

Laptop batteries don't fail on a schedule you can see coming. They quietly lose capacity for two years, and then someone is in a client meeting watching their machine die at 40%. Arqos now reads the pack in every laptop it monitors — how much capacity it still holds against what it shipped with, and how many charge cycles it has been through against what it was rated for — and tells you while there is still time to order one. Open a laptop and its battery sits with its presence history: a capacity meter and a plain line like "84% health · 612 of 1000 cycles · 71% charged". When a pack crosses the line the industry considers worn, you get one advisory — never a page, never at 2am, because nothing is down. It is a purchasing signal, not an emergency, and it stays quiet until a replacement actually clears it. For anyone running a fleet, this turns the most common surprise hardware failure into a line you can plan and budget for a quarter ahead.

Open a laptop or desktop in Arqos and you'll now find its week laid out: which hours it was awake each day for the last seven days, drawn so a pattern is obvious at a glance, with the total beside it. Its one-line summary changed too — a workstation now reads "resting · asleep 11h" or "awake 6h" instead of borrowing the CPU-and-memory line that only really means something for a server. And when a machine has genuinely been away too long, that now shows up where you actually look: on your Attention board, as its own kind of finding, with the machine's learned pattern spelled out in the explanation. Previously that situation nudged the counter on the sidebar but the board itself had nothing to show you — a number with no story behind it. Sleeping still never raises anything. That's the whole point: the quiet is recorded, and only the quiet that breaks a machine's own pattern gets your attention.

Knowing a laptop is allowed to sleep was the first half. The second half is knowing when its silence is actually strange. Arqos now learns each machine's own rhythm — the hours it's reliably awake, the nights and weekends it's reliably not — and open a workstation today and you'll see what it has worked out, in plain words: "awake weekdays ~8am–6pm, asleep nights & weekends." Two things come from that. The wait before a quiet machine is worth mentioning stops being one number for everyone: a travel laptop that's normally dark for days earns a week of quiet, while a desk machine that's never switched off gets flagged after a single dark day. And a machine that reliably wakes up for the workday and simply doesn't becomes something we can tell you about — the kind of quiet no alarm threshold can see, because no threshold knows the machine's schedule. For now the learning runs in the open but stays its hand: it records what it would have said, and the existing timing still governs every alert. Nothing new will page you until we've read those verdicts against real machines and turned it on deliberately.

A server that goes silent is an emergency. A laptop that goes silent is usually just... asleep. Until now, monitoring tools treated both the same, which is why nobody monitors workstations — the 2am "MacBook offline" page teaches you to ignore alerts. Arqos now knows the difference. The agent recognizes what it's running on (a battery means a lid means a human), and workstations get their own rules: closing the lid or shutting down for the night shows the machine as quietly resting — never an incident, never an email. On Windows, the agent literally says goodnight before the machine sleeps; everywhere else, it confesses the nap when it wakes, and any alert that fired in the gap is corrected to what it really was. You still don't fly blind: a workstation that stays dark for days — lost, broken, or walked out the door — raises the one alert that actually matters. And if a sleeping machine was the one polling your printers and switches, its checks hand over to another agent immediately, so the rest of the fleet never loses coverage.

The board used to be one long list where a printer, a hypervisor, and a server all showed the same three numbers — and most of those numbers meant nothing for most of the gear. Now the board is something you move through. Your sites read as tiles you can take in at a glance; open one and its devices group by what they are; open a class — printers, hypervisors, backup appliances — and you get a view built for that kind of device. A printer shows toner and page counts; a hypervisor shows its datastores and running VMs; a server keeps its CPU, memory, and disk. Wherever you drill to, "back" returns you exactly where you came from — the printer list, the site, the class you were in — never dumping you back at the top.

When we ship an improvement, you no longer have to remember to refresh to get it. A browser tab left open on Arqos quietly brings itself up to the latest version when you come back to it, and the desktop app does the same — so what you're looking at is always the current build, not one from before the last update. Nothing about your monitoring changes; the screen just stops drifting out of date behind your back.

Adding an SNMP check always meant typing a community string — the read-only password Arqos polls a device with. Now you can see and change that string after the fact, without deleting the check and starting over. Open a device, and each SNMP check row has a small key: click it to reveal the community Arqos currently uses and type a new one. Changing it only reconfigures how Arqos polls — it never writes anything back to the device itself, true to the rest of Arqos. The row's controls got clearer while we were in there: a key to manage the community, a quiet trash to remove the check, lined up so a printer row and a ping row read the same.

You used to have to open a device to find its IP. Now it's right on the board. A printer, switch, or firewall shows the address Arqos polls it at, tucked as a quiet second line under its name; a server shows its local address next to its operating system, where the column already promised a "host." It answers the small question that comes up constantly — which box is that, and where do I reach it — without a single extra click. Nothing about it pages or turns red: it's plain inventory, shown to your team behind their login.

As your fleet grew more varied — servers, hypervisors, printers, and switches all on one board — the site cards started to feel busy, with healthy gear competing for attention against the one or two things that actually needed a look. The board now sorts itself by what needs you, not by what kind of device it is. Anything asking for a decision today sits up top; a disk or datastore creeping toward full gets a quiet 'worth an eye' line; disks simply parked on the watch line collapse to a single line; and everything healthy — every kind — settles into one calm row of dots you can still hover to read. Add twenty more devices and the board stays just as quiet.

The network-services list on each device does more than name what's listening now — for the older, unencrypted protocols it adds a short, plain-language nudge on what to do. See Telnet and it suggests SSH; an FTP port suggests SFTP or disabling it if it's unused; SNMP v1/v2c suggests moving to SNMPv3; a cleartext directory or mail port points at its encrypted equivalent. Each device's panel summarizes how many services are worth a second look, so the answer to 'are we still running anything we don't need?' is right there. It's guidance, not an alarm — nothing pages, nothing turns red; it just helps you decide what to tidy up.

The health details arqos already read from your ESXi hosts now raise alerts instead of just sitting on a page. A datastore filling up gets a heads-up while there's still room to act — a warning as it climbs, and a louder note if it crosses into the danger zone — because a full datastore freezes the VMs it holds and blocks backups. A hardware sensor reporting a fault (a dead fan, a failing power component) opens an incident so you can catch failing hardware before it takes the host down. And if a device's clock drifts far from real time, you'll hear about it — because skewed clocks quietly break certificate checks, log timelines, and logins. Each one auto-resolves and threads its all-clear the moment the condition clears.

Open any server or network device and arqos now lists the services it's actually listening for on the network — SSH, HTTPS, a print port, a database — each named in plain language next to its port. For your servers, it reads this from inside the machine itself, so it's the real picture rather than a guess from the outside. For switches, firewalls, and printers, the device reports its own listeners over the same read-only SNMP connection you already set up. Nothing is scanned and no probe packets are sent across your network — each device simply describes itself. It answers the inventory question every review eventually asks: what is this box offering on the network, and do we still need all of it?

Point arqos at an ESXi host over the same read-only SNMP connection and its page now answers the questions that actually matter: how full is each datastore (a full one freezes VMs and kills backups — it's the quietest way a host takes a business down), how much memory is committed, and which virtual machines are running. A host that pings fine while the one VM that matters sits powered off is no longer invisible — the roster shows every VM with its power state, and honestly marks a machine whose guest heartbeat has gone quiet. Uptime got more truthful too: it's now the host's own clock, so restarting the monitoring service on the device no longer masquerades as a reboot. No vCenter required.

Open any monitored switch, firewall, or printer and it now shows what it actually is — model, serial number, and firmware version, read straight off the device, not typed in by anyone. Your asset register stops being a spreadsheet someone has to remember to update. For gear that reports them, you'll also see live environment readings — temperature, fan speed, voltage — so a failing fan or a hot chassis is visible before it becomes an outage. And each device's clock is quietly checked against real time, because logs and certificates only hold up when the clock is honest.

A monitored printer already told you it was reachable. Now it tells you what's inside: every supply's level as a bar on its page, the printer's own status (idle, printing, jammed, door open), and its lifetime page count. When a consumable drops to 10%, arqos opens one warning with the supply's exact name — stock the replacement, swap it, and the incident closes itself in the same email thread when the new cartridge is detected. Waste containers work the other way around: nearly full is the problem, so that's when they speak up. No polling schedule to set, no printer-vendor tool to install — it rides the same read-only SNMP connection you already configured.

Until now, network gear that can't run an agent was watched from the outside: is it answering, how fast. With SNMP monitoring, the same on-site probe now asks the switch itself — every port's link state, its traffic, its error counters. So instead of "the switch is fine but the file server can't reach anything," you get "port 12 lost link at 2:14pm" — with an email when a port that should be up goes dark, and an all-clear in the same thread when the cable comes back. Ports an admin deliberately shut off are respected as a choice, never an alarm. Setup is one field: add the read-only community string when you register the device, and arqos handles the rest — including the automatic failover if the machine doing the polling ever goes quiet.

Sometimes the most useful thing monitoring can do is answer one question for someone who doesn't have a login: is everything up? Each organization can now turn on a public status page — a single calm screen with the verdict at the top ("All systems operational"), every site's health, each device's dot, and an honest list of the last 30 days of incidents with how long each one lasted. Devices in a maintenance window show as such instead of alarming. There are no graphs, no addresses, no internals — just the answer. The link is a long unguessable address that you can rotate or switch off at any moment, so sharing it is a decision you can always take back.

Different fleets have different tolerances: a build server that lives at 92% disk is normal for one team and an emergency for another. The lines arqos pages on — how full a disk must be and for how long, and how long a machine can go quiet before it counts as offline — can now be set per organization instead of one-size-fits-all. The defaults haven't changed, and nothing changes for you unless your thresholds are deliberately tuned. One thing stays on the machine itself: CPU alerting is decided by the agent, which watches what's actually causing the load — no remote knob can do that job better.

If you patch servers every Sunday at 2am, arqos no longer needs you to remember to snooze first. Set a recurring maintenance window — for one device, a whole site, or the whole organization — and during those hours alerts hold automatically: no pages for machines that go quiet on schedule. Monitoring itself never pauses. Everything that happens during the window is still recorded, devices show a calm "maintenance" tag instead of an alarm, and here's the part that matters: if the window closes and a machine hasn't come back, arqos pages you immediately — "the maintenance ended and this one didn't return." So a patch night that goes wrong still wakes someone, and one that goes right wakes no one.

Any alert recipient can now also get a summary email — every morning, or every Monday — that reads the way a colleague would tell it: the verdict first ("Nothing needed you yesterday"), then what actually happened, with related dips grouped into one event instead of a page of rows, and one calm line about anything full-but-flat that arqos is watching. It's scoped to exactly what that recipient covers: their organization, or a single site. Real-time alerts are completely unchanged — the digest is a separate, optional rhythm for people who want the story without the pages.

The Fleet page used to be a long table where 25 healthy machines got the same space as the 2 that needed you. Now the fleet speaks first: a short briefing at the top — what changed this week, which disks are filling and how many days of runway they have, what dipped and recovered. Each site opens with its own sentence (how long it's been quiet, what its last incident was, how fast it recovered). Only devices with a finding get a full row, written in plain English with the trend attached. Every healthy device becomes one small dot — hover it to read its vitals, click it to inspect. And if you want the classic table, it's still there: every site has a "ledger" that unfolds to all rows and remembers whether you left it open.

Clicking a device row in Fleet now slides in the same inspector you know from Attention: what arqos thinks of that machine in one sentence, its vitals, a 24-hour CPU line, monitored apps, identity, and recent incidents — while the fleet list stays exactly where you left it. Walk the fleet from the keyboard with j and k, snooze with s, and jump to the full device page with Enter. The device name is still a normal link if you want the full page directly. Also new: click the arqos mark to tuck the navigation away — the rail collapses to just icons (the eye looks away while it's tucked) and remembers your choice.

Clicking between Attention, Fleet, Sites, and the other sections used to show a brief loading placeholder while the next page was fetched. The dashboard now quietly keeps every section ready in the background, so navigation lands on real, current content immediately — and the section you're viewing still refreshes itself every 30 seconds as always. The same work also prepared Arqos for much larger fleets: the pages that assemble your fleet's status now ask the database a fixed, small number of questions whether you monitor 20 devices or 3,000, and we verified that with a 1,000-device test fleet before shipping.

Around 5:46 PM Pacific, nine machines were reported offline that were actually running fine, and the "back online" follow-ups didn't go out until we intervened about 45 minutes later. What happened: a database maintenance job ran heavily enough to briefly delay the machines' check-in reports past the missed-heartbeat window, so downtime detection did its job on bad input. Separately, a real bug kept the recovery notices from sending once check-ins resumed — that bug is now fixed at the root, and recovery can no longer be missed: every successful check-in now closes any open offline incident for that machine, no matter what happened before it. Maintenance jobs of that kind now run gently and off-hours.

Arqos keeps the last 14 days of raw per-minute samples (CPU, memory, disk, network) for every device — enough for every chart and alert in the product, which look back at most 24 hours. Older samples are now pruned automatically every night, so the database stays fast permanently instead of slowly accumulating months of data it never reads. Your monthly evidence reports are unaffected: they're built from the durable incident record, which is kept forever.

For a few hours today, dashboard pages loaded slowly or hung — sign-in included. Monitoring itself never stopped: agents kept reporting, downtime detection kept running, and alert emails kept working the whole time. The cause was a database query pattern that got gradually more expensive as weeks of metrics history accumulated, and today's redesign tipped it over. Pages now load in a second or two, and we've added guards so a slow page can never snowball into a stuck dashboard again.

Signing in now lands on Attention: a short plain-English briefing ("3 things need you. None of it looks like a site outage."), a card for each thing that actually needs a human — what happened, which machine, and what arqos thinks is going on — and your healthy fleet compressed to one quiet line per site. Click any card and a panel slides in with the story: the evidence, the machine's vitals right now, and one-tap Acknowledge and Snooze. If you live on the keyboard, j and k walk the list, e acknowledges, s snoozes. The full fleet view is still one click away — it just isn't the front door anymore.

A server can answer every ping while the thing it exists to run — your database, your line-of-business app, the service behind a port — is quietly stopped. Arqos now closes that gap: on any agent device, open its page and add a check for a Windows service, a running program, or a local port. If the machine is up but that app isn't responding, you get a warning (not a false "server down"), it appears at the top of your fleet's "needs attention" list with the reason in plain English, and it clears itself the moment the app comes back. Quiet maintenance? Snoozing the device silences these too.

When a machine's CPU stays pinned high for a couple of minutes, its device page now names the program responsible — "top: backup.exe 82%" — right on the CPU card, so you know whether it's a runaway process or just a backup doing its job. And when a disk fills past 80%, Arqos points at the single folder eating the most space — "largest: D:\Updates\Cache — 35.6 GiB" — so you can see what to clear without remoting in and hunting for it. Both answers appear only while the problem is happening and clear themselves when it passes. They're shown to your team, not to view-only guests, because a process name or a file path is sensitive.

The "Download PDF" button on a monitoring evidence report now produces a finished, branded document in a single click — no print dialog, no "save as PDF" detour, and none of the browser clutter that used to creep in (the page title, the web address, and a page number stamped in the margins). What you get is the report and only the report: the white sheet, your logo, the fonts, ready to send to a client, an insurer, or a lender. The report is built on our own systems — your data never passes through an outside service to become a PDF.

When a server or workstation is decommissioned, you can now remove it from Arqos completely — open its device page and choose "remove device." That clears it from your fleet, stops its alerts, and permanently revokes the credentials it used to report, so a retired or wiped machine can never check in again. The Downloads page now also walks you through uninstalling the agent from the machine itself, so removal is clean on both ends: take the agent off the box, then remove the device from the dashboard.

The fleet page now opens with a "needs attention" list: every device with a problem, the reason in plain text ("disk 89% (F:)", "offline — last seen 3h ago"), most urgent first, one click from the device itself. No more scanning site cards hunting for the yellow cell — if the band isn't there, everything is healthy. And every device now answers the question its uptime raises: a new "last boot" line says why the machine last restarted — a planned Windows update, a person, or an unexpected loss of power. That last one matters: a dirty shutdown also appears in the attention list for its first day, because a server that lost power is a server worth a second look.

For about three hours early this morning, Arqos sent "offline" alerts for machines that were running fine. No monitored system was ever down: an update had idle computers reporting an activity number so close to zero our database refused to store it, and the whole check-in was rejected with it. To Arqos, everyone went silent at once. We found the exact error in the logs, fixed it the same morning, and every false alarm closed itself. The structural change: a device's "I'm alive" signal is now recorded before — and independent of — its measurements. A bad statistic can degrade a chart; it can never impersonate an outage again.

Hypervisors, switches, and storage appliances don't allow software installs — so any Arqos agent at the same site now quietly polls them for you (ping and port checks, every minute). There's nothing to assign or babysit: agents share the work as a pool, and if one goes away another takes over on its own. If the site ever loses all eyes, you get one honest "monitoring blind" notice instead of a wall of false alarms.

You can route notifications by site and severity, every incident stays in one email thread from first alert to all-clear, and anyone can acknowledge with a single click — no sign-in needed. If a critical alert sits unacknowledged, Arqos walks it up the chain you define, one contact at a time.

Rebooting a server on purpose? Snooze its alert emails for an hour, four hours, or until 8am — right from the alert email itself. Detection never pauses and the record never has gaps; only the emails go quiet. If the machine is still down when the snooze expires, you get one final alert.

A disconnected mapped drive or a stuck Windows subsystem could previously freeze an agent mid-collection — alive as a process, silent as a reporter. Every system call the agent makes now has a deadline, and a watchdog restarts the agent cleanly if a collection cycle ever stalls.

Devices are now grouped by site with problems sorted to the top, healthy fleets collapse into a one-line "all quiet" strip that shows your last incident and how fast it recovered, and a quick switcher (⌘K) jumps you to any device by name.

The agent has no remote-control channel — not a hidden one, not a disabled one. It can read health numbers and send them out; it cannot receive commands, run scripts, or update itself without your administrator acting first. That's an architecture decision, not a policy, and it's why a compromise of our service can't become a compromise of your network.

One command installs the agent on a server, and from then on it checks in every minute over an encrypted outbound connection. If a machine goes silent, you get an email within about two minutes — and when it comes back, the alert closes itself and tells you. Setup is an afternoon; the day-to-day is silence.