-
Notifications
You must be signed in to change notification settings - Fork 15
War Room
Chat that runs on your own server, for when Teams, Slack or the internet are unavailable.
It is not a Teams replacement and does not try to be. Nobody is giving up their real chat tool for it. The point is that it works on the day the real one cannot.
π§ Building on it? See the War Room Developer Guide.
When the internet drops, the onβpremise service desk is often the last thing still running on the LAN β and it already knows every analyst, which team they are in, and what is currently on fire. So it is the natural place for people to gather.
The alternative, on the day it happens, is everybody standing up and shouting across the office, or a WhatsApp group on personal phones that half the team is not in.
π Being a fallback is not a licence to make it thin. The first version had team channels and nothing else, on the argument that a breakβglass tool should stay minimal. That was the wrong instinct: a tool nobody enjoys using in calm conditions is not the one they reach for at 3am, and an outage is the worst possible moment to discover you cannot start a side conversation or find what somebody said forty minutes ago.
| Everyone | An allβhands room that always exists and is always first |
| Team channels | One per team you belong to, taken from the teams you already have |
| Your own channels | Anyone can create one, give it a topic, make it private, archive it afterwards |
| Direct messages | Between any two analysts |
| Mentions |
@name or @everyone, with a bell on every page in FreeITSM |
| Search | Across every conversation you can see, or just this one |
| Attachments | Up to five per message; screenshots show inline |
| Edit and delete | Your own messages; administrators can delete anyone's |
| Warbot | An assistant that looks things up for you |
| Situation report | Drafts the update you would send to the business |
| Retention | 7 days to forever. Attached files go with the message |
Analysts only. The selfβservice portal does not get this.
No threads, no emoji reactions, no message permalinks. These are polish on a tool people use all day; this is not that tool.
Everyone always exists and is always first β in a real outage you want one obvious place for everybody, not six team rooms and an argument about which to use.
Team channels come straight from the teams already set up in System. There is nothing to create and nothing to manage: rename the team and the channel follows, delete the team and the channel goes with it. You cannot rename or archive one, because its identity is not yours to change.
Channels you create are for an incident. Any analyst can make one β during an outage, needing an administrator to give you a room is exactly the wrong dependency. Tick Private and choose who can see it. Only the creator, or somebody who can manage the war room, can rename or archive it.
Archiving does not hide anything. It stops new messages; the conversation stays readable, because it is the record of what was said during the incident.
Direct messages are between the two of you and nobody else.
Type @ and start typing a name, then pick it from the list or just keep typing. Backspace at the end of a name removes the whole mention in one press. By default the picker inserts the first name and only adds a surname when two people share one β you can change that in the panel on the left.
@everyone notifies the whole channel. In a war room that is a normal thing to want, not an etiquette problem.
π A mention reaches you anywhere in FreeITSM. When somebody names you, a bell appears in the header of whatever page you are on β Tickets, Assets, anywhere β showing who, in which channel and what they said, with a click straight through. Optionally a desktop notification too, which is a personal setting and off unless you ask for it.
Being named shows differently in the channel list from merely having missed something, because they are different problems.
Searches every conversation you can see, or just the one you are in.
π Short things work.
P1,DC2, an error code, one octet of an IP address. That sounds obvious and is not: the database's own fullβtext index refuses to record anything under three characters, so a search forP1there would return nothing at all, with no error β the worst way for a search to fail during an incident. This search deliberately does not use it.
Up to five files per message. Screenshots appear in the conversation rather than as a filename you have to open.
Files are only ever reachable through FreeITSM, which checks you can read the channel first β a link to one is no use to anybody who cannot. They are deleted along with their message, including when retention removes it.
You can edit your own messages, and delete your own; an administrator can delete anybody's.
Both are recorded rather than silent. An edited message is marked edited, and a deleted one leaves a line saying who removed it. The text and any files really are destroyed β so a mistakenly pasted password is genuinely gone β but the conversation does not get an unexplained gap. A reader cannot otherwise tell whether something was removed or never said, and that is exactly what a postβincident review needs to know.
An assistant that sits in the room. Mention it β @Warbot how many P1s are open? β or use a command.
It can tell you: open tickets at any priority Β· which services are degraded and what customers are being told Β· what changed recently Β· who is on call Β· a machine by hostname or asset tag Β· what depends on a configuration item Β· whether there is a runbook.
π The commands work when the internet does not. Warbot's lookups are ordinary database queries running on your own server. Only understanding a plainβEnglish question needs an AI provider β so if one is not configured, or cannot be reached, Warbot says so and these still work:
/p1 open critical tickets /open all open tickets /status service status /changes what changed recently /oncall who is on call /asset <name> look up a machine /impact <name> what depends on it /kb <words> find a runbook /help this list
/changes is the one that earns its place: what changed this morning? is usually the first useful question in an incident, and it matches on when the work or outage was scheduled rather than when the change was written up β so a change raised three weeks ago and carried out at 06:00 is the one it finds.
Warbot can only read. It cannot raise, change or close anything, and it will not read a ticket out to a room β it points you at the ticket. Every reply is labelled as coming from a bot, and everyone in the channel sees it.
For the person who has to tell the business what is going on and cannot read four hundred messages first. Choose how far back to look and whether to cover every channel you can see or just this one, and it drafts: where things stand, what has changed, who is doing what, what is still unknown, and a paragraph you could send asβis.
It is told to keep speculation labelled as speculation and never to invent a cause or an ETA. Read it before you send it β it is a draft written from a chat transcript, and it goes out under your name.
β οΈ The irony is acknowledged rather than hidden. This and Warbot's plainβEnglish mode are the only parts of the war room that need the internet. Both are strictly additive: the chat never calls them, never waits for them, and does not degrade without them.
Two decisions belong to an administrator, in War room β Settings:
- How long messages are kept β a week to forever. Old messages are removed as new ones arrive, so there is no scheduled job to set up.
- The AI provider β one setting powers both Warbot's plainβEnglish mode and the situation report. Leaving it unset is a perfectly good choice.
Two belong to you, in the panel on the left of the war room: whether to show a desktop notification when you are mentioned, and whether picking a name inserts the first name or the full name.
π©Ί Check it before you need it.
System β Debug Tools β D008confirms the whole module works β channels, delete rules, attachments, retention and Warbot's lookups. Worth running on a quiet day, because this is a tool you open when things are already going wrong.
- Nothing on the page comes from the internet β no CDN script, no web font, no remote image. π What rots is dependencies, not code. A breakβglass chat is fine because it has nothing that can go stale.
- Retention is applied as messages arrive, not by a scheduled job somebody may never have set up.
- Deleting an analyst does not delete the conversation. These messages are the record of what was said; losing half of it because somebody left the company would be the wrong trade. Those lines show as Former analyst.
- Using it needs no special permission β including creating a channel and opening a DM. During an outage you do not want a permission between an analyst and the only chat that still works.
β οΈ English only at present. The other 23 locales have nowar-room.php, which falls back to English rather than erroring β outstanding work, not a decision.- Messages are not linked to an incident record.
- Warbot cannot yet be reached from outside FreeITSM; the tool registry is built so an MCP server can expose the same tools.
- π§ War Room Developer Guide β files, architecture and the traps
- Related: Teams (team channels come from here) Β· Service Status Β· MobileβFriendly
- Changelog: #1008, #1009, #1010, #1011, #1012
FreeITSM β an open-source IT Service Management platform Β· github.com/edmozley/freeitsm Β· MIT licence
- Installation
- β° Scheduled tasks (cron jobs)
- Architecture
- AI Providers
- Internationalisation (i18n)
- Timezones & Time Handling
- Theming & Dark Mode
- β¨οΈ Command palette (βK)
- π Searching inside tickets
- π Attached documents
- MobileβFriendly
-
Security
- Layer 1 β which modules you can enter
- β³ π§© Module Access Control
- β³ π οΈ Module Access β Developer Guide
- Layer 2 β what you can administer
- β³ π Roles & Permissions
- β³ π οΈ Roles β Developer Guide
- β³ π€ Why capabilities are constants
- Layer 3 β the System module
- β³ π Admin Access Control
- Hardening
- β³ π Security review response 2026-08
- β³ π‘οΈ Security hardening 2026-08
- β³ π οΈ Security hardening 2026-08 β Developer Guide
- β³ π‘οΈ Round three β plain English
- β³ π οΈ Round three β Developer Guide
- Single Sign-On (SSO)
- ποΈ LDAP & Active Directory
- Browser Extension
- API Reference
-
π REST API β how it works
- β³ π« REST API: Tickets
- β³ π» REST API: Assets
- β³ π΄ REST API: Problems
- β³ π REST API: Changes
- β³ π REST API: Knowledge
- β³ β REST API: Tasks
- β³ ποΈ REST API: CMDB
- β³ π REST API: Contracts
- β³ ποΈ REST API: Calendar
- β³ πΏ REST API: Software
- β³ π¦ REST API: Service Status
- β³ βοΈ REST API: Morning Checks
- β³ π REST API: Forms
- β³ βοΈ REST API: Workflow
- β³ πΊοΈ REST API: Network Mapper
- β³ π§ Using the API docs page
- β³ π OpenAPI specification
- β³ β OpenAPI: kept correct
- β³ π οΈ Maintaining the catalogue
- Watchtower
-
Tickets
- β³ Mailbox Authentication
- β³ π€ Email send log
- β³ Basic IMAP mailboxes
- β³ Email rendering & images
- β³ SLA Management
- β³ WhatsApp channel
- β³ π¬ Web chat channel
- β³ π£ Slack channel
- β³ π Linking tickets
- β³ ποΈ Canned responses
- β³ βοΈ Limiting replies to particular senders
- β³ βοΈ Email signatures
- β³ π The public web address
- β³ π Raising a ticket for someone else
- β³ π Merging tickets
- β³ β Splitting tickets
- β³ β Selecting several tickets
- β³ π οΈ Snoozing tickets β Developer Guide
- β³ π₯ Collision detection
- β³ β±οΈ Time tracking
- Problem Management
- Tasks
- Assets
- Knowledge
- Change Management
- Calendar
- Morning Checks
- Reporting
- Software
- Forms
- Contracts
- Service Status
- π Notifications
- π¨ War Room
- Self-Service Portal
- LMS
- Process Mapper
- CMDB
- Network Mapper
- Workflows
- Issue trackers (Jira, Azure DevOps)
- System
-
Overview
- β³ π Progress tracker
- β³ Concepts & vocabulary
- β³ Email routing & mailboxes
- β³ Settings: global vs per-company
- β³ Users & self-service
- β³ Staff cross-company access
- β³ Worked examples
- β³ Pitfalls & gotchas
- β³ Scope: what it's for
- β³ π οΈ Developer Guide (make a module multi-company)
- β³ ποΈ Case study: CMDB (a linked graph)
- β³ π§ͺ Test harness (prove it's isolated)