For a long time, the help desk revolved around a single concept: tickets.
And for most problems, that model works surprisingly well.
Something breaks, a user reports it, and the support team responds. Tickets capture the conversation between a user and the team responsible for helping them.
This model works well for many situations. But it struggles with a particular kind of problem. The kind that affects many users at once.
As we started designing incident management for osTicket 2.0, this gap kept showing up again and again.
When a shared incident occurs, tickets begin to tell the same story repeatedly.
One user reports that an integration stopped working.
Another reports the same error message.
Soon the support queue fills with variations of the same problem.
At that point the problem is no longer just a ticket. It’s something larger.
It’s an incident.
Tickets Describe Individual Problems
A ticket is fundamentally individual.
It represents a specific user reaching out for help.
Even when two users experience the same underlying issue, they still appear as separate tickets. Each conversation unfolds independently, often with different agents, slightly different descriptions, and slightly different timelines.
From the system’s perspective, they look like unrelated requests.
But from the team’s perspective, a pattern is emerging.
Support teams learn to recognize that moment quickly. The moment when the queue suddenly fills with similar reports.
The moment you realize you're dealing with an incident instead of a ticket is when different users start reporting variations of the same core problem.
Something bigger is happening.
When Problems Become Shared
Once multiple users are affected by the same underlying issue, the conversation changes.
Instead of solving the same problem repeatedly, teams need a way to track the incident itself.
They need a place to document:
what is happening
who is investigating it
what systems are affected
what updates should be shared with users
In other words, they need something that sits above individual tickets.
This is where Issues come in.
Introducing Issues
In osTicket 2.0 we’re introducing a new concept called Issues.
Issues represent shared problems or incidents that affect multiple users or systems.
While tickets track individual conversations, issues track the incident itself.
An issue becomes the central place where teams can record investigation progress, post updates, and communicate the current state of the incident.
Tickets can then be linked to that issue, giving agents immediate context about what’s happening.
Instead of piecing together the story from scattered tickets, the incident finally has a place of its own.
Incidents Have a Lifecycle
Incidents evolve over time.
At first they’re investigated. Then teams begin working toward a fix. Eventually the system stabilizes and the issue is resolved.
Issues reflect this lifecycle directly.
Each issue moves through stages such as:
Investigating
In Progress
Monitoring
Resolved
These stages help both agents and users understand the current state of the incident without needing to read through every update.
A Shared Timeline
Each issue also includes a timeline of updates.
Teams can post investigation notes, progress updates, workarounds, and final resolutions as the incident unfolds.
Some updates may be internal, allowing agents to coordinate privately.
Others can be public, giving users visibility into what’s happening and how the team is responding.
Over time the issue becomes a chronological record of the incident itself.
Connecting Issues to the Support Workflow
The real power of issues appears when they integrate with the rest of the support system.
Tickets related to an incident can be linked to the issue, giving agents immediate context when responding to users.
Users can see known issues before opening a ticket and subscribe to updates if they want to follow progress.
And when the problem is resolved, teams can respond to or close related tickets with the full context of what happened.
Instead of hundreds of isolated conversations, the system now understands that many of those tickets belong to the same underlying event.
A Missing Piece in the Help Desk
For many support teams, this layer has historically been missing.
Tickets existed. Status pages existed. Monitoring systems existed.
But the incident itself often lived somewhere in between those systems.
By introducing Issues, osTicket 2.0 gives that incident a first-class place inside the help desk.
That may sound like a small change, but for support teams it changes how incidents are understood across the entire system.
Tickets still capture conversations with users.
Issues capture the shared story behind those conversations.
And once you start looking at incidents this way, it becomes obvious that both pieces belong in the same system.
Learn More
Issues also power the new Status Page experience in osTicket 2.0, providing a public view of system health and active incidents.
If you're curious why we believe status pages belong inside the help desk in the first place, we wrote more about that thinking in Why Status Pages Belong in the Help Desk.
We’re really excited about this piece of the system and the foundation it creates for incident communication in osTicket.