Numbers that say something
| Metric | What it shows | What to watch |
|---|---|---|
| Open now | The size of the queue | Means nothing without context: are 40 open tickets a lot or a little? |
| Median resolution time | The typical time from ticket to closure | The average is skewed by single, very old cases |
| Weekly throughput | How many came in, how many were closed | Look at the trend over several months, not a single week |
| Age of open tickets | How many cases wait a day, a week, a month | The oldest ones matter most |
| No activity in the thread | Cases everyone has forgotten | Set thresholds: 7, 30 and 90 days |
| When the work comes in | Days and hours with the most incoming tickets | Helps plan duty rotas |
The median, not the average
An example: 10 tickets were closed in a week. Nine in one day, one after 60 days. The average time is 6.9 days, even though almost everything was handled straight away. The median, the middle value, is 1 day and reflects better what a typical requester experiences. Old cases are shown separately, on a list of the oldest.
How to read the data without risk
- A separate, read-only database account
The report connects with an account that has SELECT rights and nothing more. Even a bug in the report won't change the tickets.
- A block in the app as well
The report doesn't write to the ticketing system's database, and any attempt to write ends in an error. Two independent safeguards are better than one.
- A copy or replica for heavy reports
If the report computes a lot, let it read a replica, not the database the helpdesk works on.
- Checking the structure before start-up
After an update of the ticketing system, tables and custom fields can change. A command that checks the structure before running the report saves puzzles.
CREATE USER 'report_ro'@'%' IDENTIFIED BY 'strong-password'; GRANT SELECT ON osticket.* TO 'report_ro'@'%';
The osTicket API is mainly for creating tickets, not for reports, so reports usually read the database directly. All the more reason for a read-only account and for checking the structure after updates.
A monthly report for managers
- A comparison with the previous month and the queue balance: came in, closed, left.
- The most common categories and requesting departments.
- A list of the oldest open cases with their owners.
- Export to Excel for those who prefer their own summaries.
Ticket contents are often full of personal data and passwords pasted in by users. Numbers are enough for a management report, and access to the thread contents should stay with the people who need it.
Terms from this guide
- Median
The middle value: half the results are lower, half higher. In time reports it resists single extreme cases, unlike the average.
Questions and answers
Does such a report work only with osTicket?
No. The principle is the same for any ticketing system: a separate read-only account, or an API if the system offers data for reporting. Many cloud systems have a good API for it.
Isn't an export to Excel enough?
To start with, yes. A report in an app makes sense when you do it every month and want current numbers without manual work.
How many tickets do you need for the statistics to make sense?
Trends and the median become readable at a few dozen tickets a month. With fewer, a list of the oldest cases is more useful than charts.
Sources and documentation
- osTicket: documentationdocs.osticket.com
- osTicket: API documentationdocs.osticket.com
- MySQL: granting privileges (GRANT)dev.mysql.com