The 3am alarm nobody logged: building incident accountability for shops

Maui N — Sat, 17 Oct 2026 03:18:01 +0000

The alarm goes off at 3am. By the morning, three people can tell you three different things about what happened, and none of them can show you.

That is the problem I built for this week.

The three facts that never live in the same place

I spent twenty years in supermarket operations, most of it as a COO. Here is how an incident actually gets handled in a shop that has cameras:

The chiller alarm fires. Nobody hears it at 3am.
At 7am someone notices the temperature log. They remember there was an alarm.
They go to the DVR. Scrubbing back to 3am on a 16-channel recorder takes fifteen minutes if you know the machine and the timeline.
They walk the floor and ask. "Did you close it?" "Yeah, I think that was me."
That conversation is now the record. In someone's memory. Until next Tuesday.

So the shop owns three separate things: video on a recorder nobody scrubs, a name in a conversation, and a time that nobody wrote down.

Every food-safety audit I have sat through turns on the same question: who closed it, and when? And the honest answer in most shops is a shrug with a name attached.

What I built

An incident accountability system. It makes those three facts one row in a database.

alarm fires
    |
    v
open  ->  cut the video clip of the event        (proof)
          record the time it fired                (the clock starts)
    |
    v
close ->  record WHO closed it                   (the accountable person)
          record WHEN                             (how long it ran)
          generate a one-line summary             (what a manager reads)

That is it. It is small on purpose.

Run it

python3 incidents.py init

python3 incidents.py open \
  --camera chiller-1 \
  --reason "temperature above 8C" \
  --clip-from /tmp/fake-camera.mp4 \
  --clip-seconds 8

python3 incidents.py close \
  --id 2 --by "Staff A" \
  --note "door resealed, stock checked"

python3 incidents.py report

--clip-from takes anything ffmpeg reads: an rtsp:// URL from a real camera, or a file. For the demo I cut from a generated test source, because I do not have a Dahua on my desk.

The report, unedited

I ran two incidents, closed one, and left the other open. This is the actual terminal output:

======================================================================
  INCIDENT REPORT            2026-10-17
======================================================================

  STILL OPEN: 1      CLOSED: 1

  ── NEEDS ATTENTION ──
    #1   chiller-1    temperature above 8C
         open since 2026-10-14T23:35:14+00:00  (51h ago)  NOT CLOSED BY ANYONE
         evidence: /home/ubuntu/workspace/hf26-week2/clips/incident-0001.mp4

  ── CLOSED, with who and when ──
    #2   deli-2          0 min   by Staff A      23:35
         evidence: /home/ubuntu/workspace/hf26-week2/clips/incident-0002.mp4
         Fridge door ajar at deli-2 for 0 minutes; closed by Staff A; door
         resealed, stock checked.

NOT CLOSED BY ANYONE is the line that matters. Everything else in that report is bookkeeping. That one line is the thing a shop owner cannot currently get without walking the floor and asking.

And each row points at a real 8-second and 5-second clip on disk, not a timestamp to go hunting for:

-rw-r--r-- 1 ubuntu ubuntu 545953 Oct 14 23:35 incident-0001.mp4
-rw-r--r-- 1 ubuntu ubuntu 343248 Oct 14 23:35 incident-0002.mp4

Why it runs locally, and why that is not a detail

The whole thing is a SQLite file and a folder of clips on the store's own machine. The summary line is generated by an open-weight model running locally through Ollama — qwen2.5-coder:7b, Apache 2.0, 4.7 GB, on the box in the back office.

That is not a technical preference. It is the reason a small shop can use this at all.

Footage of your staff and a log of who did and did not close the chiller alarm is a document about identifiable people. Putting that in a vendor's cloud is a decision a shop owner should not have to make to get a temperature report. So I did not make them make it. Nothing leaves the building. There is no account, no signup, no API key.

The local model is the default. There is also an optional hosted fallback (INCIDENT_MODEL_MODE=api) for a deployment that would rather not run a model at all — one line in the environment, and the same code path serves both. I built it that way because "you must run a 4.7 GB model" is a real objection from a shop with one old PC, and an architecture that can only answer it with a shrug is not finished.

The local model writes the summary in one line, warm in about twelve seconds:

Fridge door ajar at deli-2 for 0 minutes; closed by Staff A; door resealed, stock checked.

If the model is down, the incident still saves. It falls back to a deterministic template. The record matters more than the prose — a missing summary I can regenerate, a missing incident row I cannot.

What I got wrong along the way

Two things worth writing down, because they cost me time:

The model call timed out on the first run. I had a 90-second timeout. The first call of the day loads a 4.7 GB model off disk, which on a small ARM box takes well over 90 seconds. Warm, the identical call is about 12 seconds. The fallback caught it and the incident saved correctly, which is the only reason it was a surprise and not a data loss. The timeout is 240s now.

I also put the model on the wrong machine at first. I ran it on a small always-on VM with 11 GB of RAM. Loading a 4.7 GB model there filled the box and froze it, which took a storefront down with it. The lesson is not "local models are bad" — it is that local inference belongs on the machine that owns the data and has the memory for it. That is the shop's back-office box, or a box you sized for it deliberately. Not the smallest thing you happen to have running.

The demo names. I had real staff names from my own records sitting in a seed file next to placeholder names. That is a trap: a screenshot in a blog post, and a fabricated name beside a real one reads as a real record. The demo uses Staff A and Staff B only. If your demo data can ever escape into a post, it is production data.

What it does not do

No mobile app. The report is a terminal command. A shop owner is not going to SSH anywhere, so this is the gap between "works" and "sellable".
No alerting. It records that nobody closed the alarm. It does not yet chase anybody, which is arguably the more valuable half.
No face or badge recognition. It records who closed it because a human typed their name. That is a trust model, not a verification model, and I am not going to blur those together.

Why this is a side hustle and not a toy

Count the shops on your street with a walk-in chiller, a DVR, and no incident log. It is most of them. They already have the camera. They already have the alarm. What they do not have is the sentence "chiller-1, 3:12am, open 47 minutes, closed by nobody" in a form an auditor will accept.

The install is a script and a folder. There is no monthly infrastructure cost, which means there is no reason to charge monthly. That is the business: a one-off setup, not a subscription.

I built it because I have sat in the meeting where this question was asked and watched three people guess.

Code: incidents.py, one file, stdlib plus ffmpeg. Open-weight model via Ollama.

I built 18 free n8n workflows. Here is the one that saved me the most time.

Maui N — Wed, 14 Oct 2026 21:16:26 +0000

I built 18 free n8n workflows. Here is the one that saved me the most time.

Most automation advice is written for people who already have their stack sorted. This is
not that. This is the specific workflow I reach for first, and why it survives contact with
real data.

The problem

Every automation project dies at the same place: the source data is messier than the demo
assumed. A CSV with three date formats. A webhook that sends a string where you expected a
number. An API that returns 200 with an error body inside it.

You can either write defensive parsing everywhere, which is unmaintainable, or normalise
once at the edge, which is what actually works.

The shape that works

Webhook / Cron trigger
        |
        v
  Normalise node      <- the only node that knows your data is ugly
        |
        v
  Validate + branch   <- bad rows go to a side branch, not a crash
        |
        v
  Do the work
        |
        v
  Log the outcome     <- so the next failure is diagnosable

Three things in that diagram are the whole lesson:

One normalise step, at the edge. Not scattered through the flow. It takes whatever
arrived and emits a known shape. Everything downstream can then assume that shape and stay
readable.

Bad data goes sideways, not down. A branch that catches invalid rows and writes them
somewhere you can look at turns a silent data loss into a list you can fix. The failure
mode you want is a row in a table, not a workflow that quietly processed 980 of 1,000.

Log the outcome. One row per run: timestamp, count in, count out, count rejected. When
something looks wrong a month later, that table answers the question in seconds instead of
an afternoon of re-running.

What I would do differently

Two things, both learned the hard way.

Do not build the alerting first. I have watched people spend a week on a notification
stack before the workflow has processed a single real record. Get the happy path working on
real data, then add alerts for the failure you have actually seen.

Do not over-abstract early. A sub-workflow that handles four cases you have not
encountered is a guess. Duplicate twice, then extract when the third caller appears and you
can see what the real interface is.

The workflows themselves

There are 18 of them, free, no signup: pdf.mauitechhub.com/workflows

They cover the boring parts that are genuinely annoying to rebuild - parsing, normalising,
retrying, logging, deduplicating. Import them, read them, change them. That is what they are
for.

If you hit one that does not do what its description says, tell me. That is a bug and I want
to know.

DEV Community: Maui N

The 3am alarm nobody logged: building incident accountability for shops

The three facts that never live in the same place

What I built

Run it

The report, unedited

Why it runs locally, and why that is not a detail

What I got wrong along the way

What it does not do

Why this is a side hustle and not a toy

I built 18 free n8n workflows. Here is the one that saved me the most time.

I built 18 free n8n workflows. Here is the one that saved me the most time.

The problem

The shape that works

What I would do differently

The workflows themselves