Built 2018 · Status Retired · Stack Laravel 5.6, PHP 7.1, Laravel Spark, MySQL, Vue 2, Pusher, Twilio, Redis
AlertFlow was an incident management system. One person filed an issue against a service, everyone subscribed to that service was notified by text or email, and the issue page became the single place where the response was coordinated and recorded.
Purpose
When a shared service breaks, sending the notification is the easy part. The hard part is knowing whether anyone received it. Someone reports a network outage or a water leak, a handful of messages go out, and until a person replies nobody can tell whether the right people are on it or whether the alert is sitting unread on a phone lying face down on a desk. I wanted a system where acknowledgment was captured automatically and shown to everyone, so a group could stop guessing and get on with the fix.
What it did
The data model had three layers. An instance was a self-contained department, so one organization could run separate instances that shared neither services nor users. Inside an instance were services, which were the things that could break. Users belonged to an instance and subscribed to the services they cared about. Issues were filed against a service, which meant the notification list came from the service rather than from whoever happened to be reporting. That detail mattered: a staff assistant who noticed a problem could open an issue without knowing who fixed that kind of problem, and the right subscribers were paged anyway.
The acknowledgment mechanism was the part I cared most about. Each outgoing notification carried a link unique to that user and that issue. Clicking it logged the recipient in without a password prompt and registered the acknowledgment, which then appeared on the issue for everyone else. That turned a one way broadcast into a status board: who has seen this, who has responded, where the issue stands right now. The issue page also carried real-time chat and task assignment, so the work happened next to the record instead of in a side channel, and reporting covered issues, responses, and time spent on resolution.
Delivery was deliberately outsourced. Email went through an external SMTP provider, Mailgun, and text messages went through Twilio, which at the time cost about three quarters of a cent per message.
Features
- Instances partitioned the system by department, each with its own services and users, so an IT group and a facilities group could run side by side without sharing configuration.
- Services and subscriptions defined what could break and who heard about it. The worked examples were an IT instance carrying network, email, and phone, and a facilities instance carrying electrical, plumbing, and grounds.
- Issue creation by any member of an instance meant the person who spotted a problem did not have to be the person who resolved it.
- Text and email notifications went to every subscriber of the affected service as soon as an issue was opened.
- One-click acknowledgment used a per-user, per-issue link that logged the recipient in and recorded receipt.
- Real-time status showed who had responded and the current state of the issue.
- Chat and task assignment kept resolution work attached to the issue itself.
- Reports tracked issues, responses, and time spent on resolutions.
- Mobile first design, on the assumption that an incident notification gets read on a phone rather than at a desk.
Impact
The gap it closed was acknowledgment. Without it, notifying a group meant sending a message and hoping. With it, the issue page showed who had seen the alert without anyone having to ask. The honest scope is small and I will not dress it up: I had a working instance running in 2018, and I was still demonstrating the system in 2021. The hosted application has since been shut down.
Screens
Links
The original post linked the source at github.com/jazmy/laravel-alertflow. That repository is no longer public, so there is nothing live to link to.
