Local incident logging for retail: a case study in self-hosted accountability

On October 14, 2026, developer Maui N published a detailed case study on building a self-hosted incident accountability system for physical retail shops. The project addresses the common operational gap where alarm events, video evidence, and staff actions remain disconnected, leading to unreliable records during audits.

What happened

The author, drawing on twenty years of experience in supermarket operations including a role as COO, identified a recurring failure mode in small shops. When a chiller alarm triggers at night, such as at 3am, it often goes unheard until morning staff notice temperature logs. Investigating the event requires manually scrubbing through DVR footage, which is time-consuming, and relying on memory to determine who resolved the issue. This results in three separate facts—video, a name, and a time—that rarely align in a single, auditable record.

To solve this, the author built a lightweight, command-line tool that unifies these data points. The system records when an alarm fires, cuts a specific video clip from the camera feed as proof, and logs who closed the incident and when. The output is a simple terminal report that highlights open incidents with the phrase "NOT CLOSED BY ANYONE," providing immediate clarity that is currently missing in most manual workflows. The tool stores everything locally in a SQLite database and a folder of video clips, ensuring no data leaves the premises.

Key details

• The system runs entirely on-premise using a SQLite file and local video clips, avoiding cloud vendors to protect staff privacy and sensitive footage.
• Summaries are generated by a local open-weight model, specifically qwen2.5-coder:7b (4.7 GB), running via Ollama on the shop’s back-office machine.
• If the AI model fails or times out, the system falls back to a deterministic template, prioritizing the preservation of the incident record over the quality of the prose.
• The initial model load time on an ARM box exceeded the original 90-second timeout, causing a surprise failure that was mitigated by increasing the timeout to 240 seconds.
• The tool does not include face recognition or badge scanning; it relies on a trust model where staff manually enter their names when closing an incident.
• There is no mobile app or automated alerting system yet, meaning the tool records incidents but does not actively notify staff to resolve them.

Background

Self-hosting in this context refers to running software on local hardware within the business premises rather than relying on third-party cloud services. For retail environments, this approach is critical due to privacy regulations and the sensitive nature of video surveillance involving identifiable employees. By keeping data on a local machine, the shop owner retains full control and avoids the legal and ethical complexities of uploading staff footage to external servers.

The use of large language models (LLMs) locally, via tools like Ollama, allows for automated summarization without internet connectivity or API costs. However, local inference has performance constraints, such as cold-start delays when loading multi-gigabyte models into memory. Understanding these hardware limitations is essential for designing reliable fallback mechanisms, ensuring that core data integrity is maintained even when auxiliary features like AI summaries fail.

Why it matters

For teams managing self-hosted infrastructure, this case study highlights the importance of designing for failure modes specific to local environments. The timeout issue encountered during the first model load demonstrates that local resources behave differently than cloud APIs. Engineers must account for disk I/O speeds and memory loading times when setting timeouts, rather than assuming consistent network-like latency. This reinforces the principle that observability and robust error handling are just as critical in on-premise deployments as they are in distributed cloud systems.

Furthermore, the decision to prioritize data retention over feature completeness offers a valuable lesson in product design for regulated industries. By ensuring that the incident row is saved even if the AI summary fails, the system guarantees that the audit trail remains intact. This "record first" mindset is crucial for any software dealing with compliance, where missing data is far more damaging than imperfect formatting. It shows that self-hosted solutions can offer superior privacy and control, provided they are engineered with realistic hardware constraints in mind.

What you can do

• Audit your current incident response workflows to identify gaps where video, timestamps, and human actions are stored in separate systems.
• Implement local fallbacks for any AI-dependent features in your self-hosted tools to ensure core functionality survives model failures.
• Review timeout configurations for local services, accounting for cold-start delays and disk I/O rather than just network latency.
• Sanitize demo data rigorously, ensuring that no real production names or identifiers appear in screenshots or public code repositories.
• Consider the privacy implications of cloud-based logging for sensitive data, and evaluate whether on-premise storage better meets your compliance needs.
• Start with simple, script-based tools to solve specific operational problems before investing in complex, full-featured platforms.