Rebuilding Incident Commander As A ColdFusion App
Years ago, I created a simple Firebase and Angular app for triaging incidents at work. The app allowed the incident commander (IC) to record notes and share messages in Slack (via copy-paste). But, one thing that it never allowed for was the storing of supporting screenshots. To remedy this (and as a fun thought experiment), I've rebuilt my Incident Commander app in Adobe ColdFusion with a MySQL data store; and, it now allows screenshots to be embedded within the shareable timeline.
Run this app at www.incident-commander.com.
View this code in my Incident Commander project on GitHub.
Instead of having to build both an Angular single-page application (SPA) and a ColdFusion API, this rebuilding of the Incident Commander app uses a more traditional multi-page application (MPA) style of architecture. As much as I adore Angular, this lighter-weight approach allows me to move faster and experiment; and, applies constraints to the user interface (UI) complexity which keep me focused.
The Incident Commander app consists of three main screens. First, the general settings page. This is where the IC can enter a description of the perceived incident, select a severity, a provide a link to the video triage conference call.
The second page is the status update entry. This is where the IC records new insights about the ongoing incident investigation. Each message supports a limited set of Markdown formatting rules and can have an uploaded screenshot. The UI only allows for one screenshot image to be uploaded during message authoring. However, additional screenshots can be uploaded (for a given message) by editing a status update.
You might notice in the screenshot that below the status update intake form there's another form that provides a Slack-friendly message. The goal of the Incident Commander tool is to make it easy to share information about the current outage. And, part of that sharing is pushing updates to Slack so that the rest of your team can be kept in the loop.
I don't have a fancy Slack integration; but, the Slack-friendly message takes the incident settings and the recent status updates and serializes them into a formatted message that you can copy-paste into your incident triage Slack channel. So, for a status list that looks like this (the top 3 most recent status updates are included in the Slack message):
... copy-pasting the message into Slack looks like this:
Aside: Slack won't automatically apply the formatting. You have to use the key-combination,
CMD+Shift+F, to have Slack apply the formatting after pasting it into the Slack UI.
In addition to the incident description and the most recent three status updates, the Slack message also contains a link to the shareable incident timeline and a link to the incident triage video conference call. This way, anyone who's jumping into Slack during the investigation can quickly get up-to-speed and join the video call (if desired).
The timeline URL in the above screenshot links to the third page of the Incident Commander app, which is the passive overview of the entire investigation complete with screenshots. This is where other team members can occasionally pull updates if they want to know what's going on but don't necessarily want to sit-in on the video call or closely monitor the Slack channel:
And then of course, there's a way to export your timeline data and delete your incident if you don't want your proprietary information living on someone else's server.
And that's basically it at the moment. I'm building this in public, so you can see all the ColdFusion, MySQL, Apline.js, Less CSS, and ParcelJS details on the GitHub page. I'm using Docker with CommandBox to run it locally.
As much as I enjoyed the ability to host the original version of this application on Firebase, it ultimately felt like a dead-end. Meaning, I didn't know how to go about evolving the application when using a DB-as-a-service approach. Now that the code is wholly contained within my domain of control, I feel like there's a path forward in this experiment—a way for me to iterate on the idea and try out new ideas.
Reader Comments
Sounds like it'd be fun to add Slack integration. If I could ever get two nickel's worth of time to rub together, I'd be glad to chip in!
@Will, ha ha, I know what you mean - I feel like I'm sprinting from one task to another! I know we have done Slack integration at work before - I think it's an OAuth workflow. But, I've only consumed it, never implemented it before. If you have any pointers, I'd be all ears!
I can imagine being able to run this as an app within MS Teams
Adds a bit of complexity, but if you run your incident through a ChatGPT, maybe you can get a starting point for a summary/report for the incident.
@Danilo,
Oh that's a cool idea as well. To be honest, I've very little experience consuming ChatGPT (or any AI models) from an API standpoint—I've only used the chat interfaces to ask questions. But this seems like it would be something that speaks very much to the strength of the current AI ecosystem. I'll put that on my list of things to look into.
Re: MS Teams - can you add more color to your thinking there. I'm not familiar at all with MS Teams, so I don't know what it means to run something "inside". I've always thought of it as a chat app - but, it is more of a platform?
I love it when you provide a video version of the article. I'd much rather listen to you walk me through it than read it myself. I think I retain it better too. Thanks 🙏
Also...head's up! I think there's something off on your commenter timestamps. It says your last message was posted on "Nov 18, 2024 at 6:19 PM" but as I read this, it's only 10:44 AM (Pacific)
@Chris,
Have you been sent from the future?! 😉 Yeah, this is an issue on my end - the dates are just coming out of the database in UTC time, so it's like 8-hours ahead of your and 4-hours ahead of me. But that gives me an idea... let me work on that.
Glad you like the video - I used to do videos all the time when it was Angular stuff; but, I never really got into the groove of doing them for ColdFusion stuff. It's something that I want to be better about.
@Ben
Yes, Teams is more than chat, you can have meetings (voice calls, video/screen sharing), file/document storage (with versioning), "tabs" that are web pages, Word document, Excel spreadsheet, etc., and you can add apps (assume that there are many paid options).
Ahh, very interesting. I had no idea. I know that one our dev-teams built a login flow that could be used by MS Teams; but, that's as much I know about it (other than that they had a heck of time getting it to work consistently - some cookie persistence issue that was causing them much grief).
It's funny how much products evolve under our own nose. Meaning, I use Slack; but, I'm sure I only use like 10% of what's there because it was the 10% I learned 8 years ago. And now, I'm so set in my ways (or rather, my ways deliver much value to my life) that I don't often think to explore the new features of the products that I already use.
Life is tricky 😆
@Ben Nadel,
And I'm sure there's much more to Teams that I'm not aware of, I haven't even touched adding apps yet.
Given the current implementation, I think that Incident Commander could be added as a Web page within Team, but not sure I'd be able to use it for more than testing. While I do personally trust you, I'd be uncomfortable using it for an actual work incident, as I'm not sure others in the organization would extend that same trust to a free site. Interestingly, if it were a paid product, there wouldn't be a question about trust, so, maybe you can use your Feature Flags and start adding new features....😉
Thankfully, we don't have incidents often enough that there's pressure to have better tracking of them.
@Danilo Celic
Ben has the code available on Github:
That's in the OP.
@Danilo,
100% this is mostly just a tool that I use to run incident triage at work. And, since we've embraced feature flags, our number of incidents have all but stopped. So, it's probably not something I'll have to use much anyway. That said, it's a nice playground to be able to think about problems. There's something nice about having some tangible to work with (as opposed to isolated demos).
For example, one thing that I want to work on in is what to do if people want to add a password to a given incident. I'll need something that isn't passed-around in the URL (ie, so it would never show up in any URL logging); but, what does the right solution there look like? Some sort of cookie, I think, but I haven't thought it through yet. But, this kind of stuff is easier to think about when you have a real application to work against.
@Will
Aware that code is available...Ben's reading audience extends beyond those that can (or able to) run ColdFusion within their environments. Actually had a thought about taking a stab at implementing this in .NET, before I remembered the extent of my work backlog, much less my own personal backlog. 🤣
@Ben
Unless you have an explicit finite set of features you're wanting to try out, if you're wanting to use this as an application to apply Feature Flag teaching to, this being an actual product will eventually need to be a reality, or it will likely wither on the vine through lack of interest in the underlying problem.
Having accounts and ability to add other accounts or team members to an incident seems like the way it would really need to evolve to, but in the meantime, maybe the app can generate a GUID, and then the user can copy it from the webpage (or maybe you can offer and add to clipboard via button click -- bonus feature flag opportunity?) into their chat application (not ideal), or maybe allow "invites" where you send the link and password (perhaps per individual) via email.
Once you get into multiple events, then you'll probably need to track emails and incidents so that the right incident password can be sent over/recovered.
The more I type the more I think about features that might be useful....maybe a conversation would be in order rather than trading comments...damn the backlogs 😬
Since this is freely available at the moment, I'd be a little concerned about usage by spammers, or more nefarious characters.
@Danilo,
Right now, this is primarily just a fun experiment (and would be something that I would personally use but might not appeal to anyone else). That said, you mention adding something like a GUID - so, I'm kind of exploring something a little bit along those lines right now.
The "incident token" that I have in the URL is very large and should be sufficiently broad to prevent a brute-force attack. As such, what I wanted to do was supply an additional means of security that isn't present in the URL so that it doesn't get logged by the server or the firewall or any of that jazz.
But, at the same time, I don't want to raise the barrier of entry (especially in the middle of an incident). So, what I'm thinking is that after the incident is created, I can make it possible to add a "password". Then, anyone else who attempts to access it will have—in additional to the URL token validation—a cookie-based security check (think something like a JWT but without the need for as robust a specification).
Now, I think I'd still want to include the password in the Slack-ready message so that it can be easily shared internally; but, anyone who clicks on the link would still need to enter the password in order to access the web-based UI.
Anyway, that's what I've been rolling over in my head the last day or so.
@Ben Nadel,
You could look at JSON web tokens, too. But encrypted to a single, URL-safe string. IIRC JSON web tokens are plain-text, but there's a signature or something on them that your server can verify. Been a while since I've looked at them. You know... since we're brainstorming! Heh. One of these days I'll get on the CF Slack channel.
Post A Comment — ❤️ I'd Love To Hear From You! ❤️
Post a Comment →