Is That App Still Running in a Year? Mine Is. Running Was Never the Hard Part.

Nexus Labs sent its NexusCon recap last Tuesday. The line that got an ovation on the demo stage came from Colin Jenkel of Amazon: "do NOT try to sell or pitch me another AI chatbot." Of the vendors who applied to demo, only one in five submitted something directly about AI. Of the sixteen demos that made the stage, most led with one of three outcomes instead: the product saves time for skilled labor that is hard to hire, it makes an invisible condition of the building measurable, or it closes the loop from a problem found to a problem fixed. AI was in nearly every demo and the headline of almost none. The night-one award went to an OT security platform that mentioned its model once, as the engine in the back.

The argument that did not get settled was in the owner and vendor symposium. Some building owners, confident in their data layer, said they are buying fewer applications: the AI agents already in their organizations let a building engineer stand up a small in-house app that fits exactly. Cory Clarke, the chief product officer at Greenlite, pushed back. Building owners are business and finance organizations, not engineering ones, he said, and a building engineer can certainly make a small useful app. His question was whether that app is "still running in a year."

I am a building engineer who stood up a small useful app. It watches a sump pump through a smart plug and has done so since February. So I took his question literally and checked.

Yes

The host it runs on has been up since September 2 without a restart. Between October 16 and this morning, eleven days in which I did not look at it once, the monitor wrote 10,093 lines of log. It sent 1,574 heartbeats, one every ten minutes, none missing. It ran the pump 1,322 times. The daily status mail arrived at eight every morning, ten mornings, and every subject line began with [OK]. A backstop process polled the plug every two minutes and logged a status line 7,855 times. A second analyzer classified the situation every fifteen minutes, 1,096 verdicts. A language model read the logs four times a day and wrote 45 notes.

By the test Clarke proposed, the app is running. It is, if anything, more running than most things I own. And having looked, I think his question is the right one to ask and the wrong one to stop at, because the same eleven days contain three things that "running" does not cover.

Ten dry days, same log

The pump controller has been in its top escalation tier since 1:16 am on October 6, which is twenty-one days today. In that tier it ignores the float and runs the pump for 120 seconds every 12 minutes, 119 pulses a day, and records the power at the end of each pulse. Here are the eleven days against the rain at the pump's coordinates.

A storm day and ten days without a drop produced the same row. Across all 1,322 pulses the pump drew a median of 495 watts, never under 425, and not one pulse ended before its timer. Two weeks ago I wrote that in this tier the log cannot notice rain. It cannot notice drought either. The controller sets every number this system reports except the end-of-pulse watts, and the watts have one value.

The only instrument left with any freedom is the plug's energy counter, and it moved: 21.8 kilowatt-hours in those eleven days, two a day, about four motor-hours daily for a one-third horsepower pump, with nothing falling from the sky to pump. There are three stories that fit a pump doing that. The float is stuck and the pump is drawing wet-looking watts on a near-empty pit. Water is recirculating through a check valve that no longer holds. Groundwater really is arriving at that rate. Ten dry days make the third story the hardest to keep believing. The way to find out is to lift the lid and watch one pulse, which is a line in my own status document dated February 27. Today is day 242.

The one alert, six times

In eleven days the system sent a person exactly one kind of urgent message. At 6:01:59 am on October 19 the plug read the line voltage at 130.4 volts, the threshold is 130.0, and the monitor emailed me and pushed a phone notification. Then it did so again at 6:11, 6:23, 6:35, 6:47 and 6:56. Six emails, six pushes, 55 minutes, one event.

The cause is five lines of code I wrote in the spring. The check runs every thirty seconds. It sets a flag when the voltage is out of range so it will not alert twice, and it clears the flag the moment a reading comes back in range. There is no gap between the trip point and the reset point, and no minimum time between repeats. The grid spent about an hour hovering at 130 to 133 volts, so the thirty-second samples crossed 130.0 at least five times, and each crossing was a brand-new emergency. The backstop process in the same repository has a one-hour repeat window for exactly this reason. I wrote both.

What makes it worth a section rather than a shrug is that the alert was right. Of 28,625 heartbeat voltage readings since February, the median is 122.2 volts and the 99th percentile is 124.0. The eight readings at or above 126 volts in the entire history all come from that hour, and the peak, 132.9, is the highest the plug has ever reported. The utility's own standard holds service voltage at the meter to 126 volts, 127 in its looser band. Something on the grid was out of spec for an hour before dawn, and a $25 plug caught it. Then it told me six times, which is the fastest way I know to teach a person to delete the next one unread.

Credit where it is due: the language model's 6:05 am note, written three minutes after the first email, singled out the voltage as the one real signal of its window, noted that the monitor had already alerted, declined to pile on, and suggested a human take a look if it did not settle within two hours. It settled at 7:18. That is the most useful thing the watcher has written in a month, and it is also the one time this fortnight that any layer of the system showed the restraint I failed to code.

What ran and what was fixed

The third thing is the one that answers Clarke's question for real. The plug dropped off the network 22 times in eleven days, 84 failed reads, the longest stretch seven and a half minutes before dawn on the 18th and another of four minutes at 2 am this morning, with the discovery scan coming up empty five times in a row. The assessor noticed four of the episodes and emailed an inbox that no person reads. The watcher wrote "no Shelly unreachability" in seven of its 45 notes.

On October 16 I filed two one-line fixes for that watcher: change a template sentence that tells it the float is "NOT stuck" whenever a counter is zero, and change its prompt to say how much log it actually reads. Neither needs a restart. Eleven days later the template still says it, the prompt's modification time is still June 2, and the watcher said "not stuck" fifteen more times. Meanwhile a notification tier that lost its recipient list in the summer skipped another 1,355 messages, bringing the all-time total to 8,117, every one logged as sent.

Then I ran the audit I built in September, which counts the distinct values each status field took over the window. Sixteen of twenty fields took exactly one value in eleven days. The assessor's class, 1,096 times HIGH_INFLOW. Its severity, 1,096 times INFO. The digest's overall status, ten times OK. The backstop's "last action," 7,855 times "cooling rest expired," which I established last month is the only value that field is capable of printing. The four fields that varied were the relay being on or off, the pump running or not, and a rate that has one mode. On September 26 that audit flagged six fields. The system has become more consistent, and consistency is what a field reports when it has stopped carrying information.

Three outcomes, graded

Nexus Labs said the demos led with three outcomes. Here is my small app against them, honestly.

• Saves skilled-labor time. Yes. Zero trips to the basement in eleven days. The one two-minute task that all of this instrumentation exists to inform, looking at the pit, has not been done in 242 days. The app saved the labor by absorbing it.
• Makes invisible conditions measurable. It did, in February. Then it put the pump on a timer, and in that mode the one condition that matters, whether the float opens on its own, is structurally unobservable. The invisible condition it made measurable this fortnight belonged to the power company.
• Closes the loop from found to fixed. Found: roughly sixty numbered findings since August, most of them one-line defects. Fixed: a growing markdown file. The loop runs from the log to the file and stops.

So, to the owners who are building their own: Clarke is right that the app will probably still be running. Running is what computers do; mine has not missed a heartbeat in eleven days and would not have missed one if the pump had died on the 17th. And to Clarke: the SaaS alternative has the same problem one layer up. A vendor's dashboard also reads [OK] ten mornings in a row, and the owner has even less ability to ask what the field is capable of saying instead.

The question that distinguishes a monitor from a running process is not whether it is up. It is who graded it last month, and what did the grade find. Mine found a correct alert sent six times, ten dry days indistinguishable from a storm, two fixes filed and not applied, and sixteen fields out of twenty that could not have told me anything. That is a worse report card than the daily digest's ten OKs, and it is the only one of the two worth reading.