Internal and External Status Updates for Service Status

[dschipfel]

Current situation

The Service Status module is a great way to communicate outages, maintenance windows, and service disruptions. However, all comments are currently treated the same way, which can make it difficult to distinguish between internal documentation and customer-facing updates.

Suggested improvement

Introduce two types of comments within incidents and service status updates:

• Internal Comment

  • Visible only to analysts and administrators
  • Used for troubleshooting notes, internal communication, and technical details

• External Comment

  • Visible in the Self-Service Portal
  • Used for customer-facing status updates and communication

Self-Service Portal Enhancements

External comments should be displayed in the Self-Service Portal together with a timestamp.

Example:

Date/Time	Status Update
2026-08-25 08:15	Incident identified and under investigation
2026-08-25 09:05	Root cause identified
2026-08-25 09:45	Service partially restored
2026-08-25 10:20	Service fully restored

Expandable Update History

To keep the Self-Service Portal clean and easy to use, the status update history could be displayed in a collapsible section.

Suggested behavior:

• By default, the update history is collapsed
• Users can click "Show Updates" or "View History"
• The timeline expands to show all external updates and timestamps
• Users can collapse it again if desired

Benefits

• Better separation of internal and external communication
• Improved transparency for end users
• Reduced need to create multiple incidents or workaround communications
• Professional status communication during outages
• Cleaner Self-Service Portal interface
• Improved customer experience

Many organizations provide regular status updates during incidents. Having dedicated external comments with timestamps and an expandable history would make the Service Status module much more useful as a customer communication tool while still allowing internal teams to document technical details separately.

[edmozley]

Hi Daniel @dschipfel

Thanks for this one - it is built!

Internal and external. Saving an incident with something in the comment box adds an entry to its timeline, and you now choose who it is for. Internal is the default, and it resets to internal every time the dialog opens - publishing should be the deliberate act, and the choice is not carried over from the last incident you touched. Each entry in the timeline is badged so you can tell afterwards which is which.

The portal. Under the service list, each incident appears with the services it affects and a "Show updates" link that opens a timestamped table - what was said and when, oldest first, so it reads as the story of the outage. Collapsed by default, and the updates are only fetched when somebody opens one.

It is off until you turn it on, under System - Service status on the portal. That is deliberate rather than cautious: switching it on publishes incident titles, and titles are written for your own team rather than for customers. Worth reading yours before end users do. Everything written before this feature existed is internal and stays internal.

How far back the portal goes is configurable: only what is happening now, that plus anything resolved in the last so-many days, or the full history. The middle one is the default - a resolved entry is the most reassuring thing on a status page for somebody who was hit by the outage an hour ago.

Two things you did not ask for, which came out of testing it properly. I realised that fixing a typo used to post the sentence a second time, so a reader saw it twice with the wrong version first - and that merely opening an incident and pressing Save republished the last message. Neither mattered much while the timeline was internal. Both are fixed: saving only adds an entry when the status, the wording or the affected services actually changed, and each entry now has a correct and a remove action so a typo is fixed where it is. You can also change whether an entry is internal or external after the fact, so a note that should have gone out can be published without retyping it.

---

Things to try:

1. Turn it on under System - Service status on the portal, and choose how far back you want it to go.
2. Raise an incident with an internal note - something you would never show a customer - and check the self-service portal. The incident should not appear at all.
3. Add an external update to the same incident. Now it appears on the portal, with only that one update visible.
4. Expand it on the portal. You should see the external update with its timestamp, and no sign of the internal one.
5. Fix a typo in the external update with the correct action, and check the portal again - the wording should change, not double up.
6. Open the incident and press Save without changing anything. Nothing new should appear on the timeline.
7. Resolve the incident without writing a new comment. The timeline should record the status change on its own rather than repeating your last sentence.
8. If you have a test end-user account, worth doing step 4 while signed in as them rather than as an analyst - that is the view that matters.

There is a new section in the in-app help under Service Status, a plain-English one in the portal's own help for your end users, and a wiki page:

https://github.com/edmozley/freeitsm/wiki/Service-Status