How do you track IT events that are not support tickets?
Posted by Aim_Fire_Ready@reddit | sysadmin | View on Reddit | 77 comments
Background: I have always worked alone in IT, I'm self-taught, and my largest env was 300 students and 40 staff at a small, private K12. I have ZERO experience with "standard" IT envs.
How do IT depts typically record when actions are taken, such firmware updates, configuration changes, or other "internal" events that are noteworthy but not specifically a support ticket?
I can jerry rig an existing tool to make it work or vibe code something from scratch, but I don't want to reinvent the wheel. Shirley, this is a normal part of responsible IT management.
mikevarney@reddit
We create tickets for ourselves. We then put details of the update in the ticket and close when done.
By creating tickets for yourself you create a trail so if a problem happens other staff can see there was an update done on a certain date.
jasondbk@reddit
Or so I remember wtf I did.
Biggest benefit: find out who touched it last because that person broke it.
bad__gas@reddit
Don’t feel silly. This is a good question and good thread. Love many of these comments. This is something we all encounter.
doubleknocktwice@reddit
In my head
JustFrogot@reddit
Change control, projects, tickets. There are options depending on what platform you use
BidAccomplished4641@reddit
Already said, but the proper ITIL method is a change ticket. In a small environment you can get by with a regular service request/support ticket, just to get it documented.
Aim_Fire_Ready@reddit (OP)
Do you have any good resources for learning ITIL? NGL, whenever I looked it up in the past, what I found was too vague to be actionable.
BidAccomplished4641@reddit
Check out Jason Dion ITIL foundation training on YouTube. It’s a buzzword-heavy framework, so be warned. I’d focus on service desk(help desk) and change management for what you’re looking for. Just remember that you don’t need to implement it strictly, depending upon your needs and your organization. Some of the processes are just too complex for a small group, but learn the concepts and adapt them for your needs.
Change management is cool because it makes you pause, consider who could be affected by your change, what you need to communicate, how you’ll roll back if it goes wrong, and how well understood the change and the risks of it are.
Aim_Fire_Ready@reddit (OP)
Awesome, thanks for the tip. I’ll look up Mr. Dion.
Shen_31@reddit
most teams don't treat firmware updates or config changes as support tickets, but they still log them somewhere for tracking, mostly so you have a paper trail when something breaks and you need to figure out what changed recently. the term for it is usually "change record" or "change log."
smaller setups get away with a shared doc or spreadsheet honestly. once the environment grows though it gets messy fast, especially when you need to connect a change to a ticket ("oh that outage happened right after we pushed that firmware update").
some helpdesk tools like siit let you log both user requests and internal changes in the same place so it's easier to trace. but even a simple wiki works if you're still solo.
mixduptransistor@reddit
Why can't they be tickets?
On my team all work is a ticket. Now, we have our project work in Jira and incidents and service requests come in through Service Now, but everything is a ticket somewhere
Aim_Fire_Ready@reddit (OP)
TIL these events/changes can be tickets apparently. I have a very narrow view of "tickets" apparently since I only associate them with a request for support from someone outside the dept.
CARLEtheCamry@reddit
I actively dislike the term "ticket" because it's too vague.
I don't know if it's like ITIL or whatever, but we do 3 different types of "tickets" :
1) Incident. This is break fix. Server is down, network is down. You can assign escalation SLAs to these if needed.
2) Request: This is a different kind of non-urgent request. We keep a 10 day SLA on these. Something like a lifecycle replacement of a laptop that isn't break/fix.
3) Change. This is for any planned work on production systems with any risk of causing an outage. Need to have a back out plan, specific schedule, and management approval before proceeding. "Cover Your Ass" is the name of the game. I put one in for things as mundane as Windows patching every month
awetsasquatch@reddit
It's kind of like a bastardized version of ITIL, but close enough for the average person who didn't have to study for that test.
CARLEtheCamry@reddit
Adding "ELI5 ITIL" to my resume
Lethbridge_Stewart@reddit
I look at it like a journalling filesystem: Write down what you're about to do before you do it. You don't have to use tickets per se, but since at their most basic these tasks tend to follow the same flow as user requests, then it makes a lot of sense to use the tools you already have.
Another way this helps is making your work visible - building a log of how much you're doing that most people won't ever notice. (the sysadmin bible covers hits and more). It's a huge benefit when it comes to negotiating a raise or hiring a junior.
Own_Candidate9553@reddit
Just be your own customer! You deserve support too.
Taftimus@reddit
I just create a ticket in our board and assign it to myself for any adhoc/maintenance work
coldfisherman@reddit
everything is a ticket. We actually use OpenProject (which I highly recommend as the actual work-horse, while something like Jira is kept specific of code work) so we have "Work Packages", which can be literally anything. Then you can link it to claude code via an MCP and be like, "John smith asked for this" and paste in some email or chat or whatever, then say "make me a work package and log 2 hours on it, then leave it in status 'to-review'" or whatever status you want stuff to be in before you close it out and want human eyes on it..
SirLoremIpsum@reddit
That's a misnomer because everything is a ticket.
You do not work on things that do not have tickets.
"I changed a firewall configuration. Here is the ticket that spells out the exact change being made (pre and post state) and the rationale for the change. If necessary someone approves it".
Why would you change that config without writing down what/why, and assigning a level of effort?
At the end of the day/week/month you run a report or have something to show for it.
TheGooOnTheFloor@reddit
If an IT Event is not from a ticket then it is a change. Implement Change Control to schedule, approve, and track them. (ITIL)
Helpjuice@reddit
If it is an IT event it gets a ticket, if it has not ticket it does not belong to IT!
If you are making changes to a system it should be tracked via a change control board system even if that person is you, and the boss. A ticket should then be created to start the work and track what happens during that time and related to the approved change control item.
Your change control should have what you are doing, why you are doing it, rollback plan, if it's something that can be rolled back, and approvals from others than yourself approving the work and verifying the plan is sound.
This creates accountability, better understanding of what in the world is going on, adds something auditable for 3rd parties and is a CYA in case something horrible goes wrong it forces you and others to have a backup plan for the uh oh that could happen to include actually making a backup before starting the work in case the entire box dies and never comes back online.
PC509@reddit
We use Azure DevOps Boards for it. But, any kind of thing like that would work. Just something you can search, find the documentation you used, notes, versions, etc.. We have To Do, Doing, Done, Closed columns and can see what projects/non-ticketed things that people are working on or completed.
Comes in handy many times years after something was done and we need to do it again. We have the notes from the last time (sometimes previous person since they're long gone).
However - with things like that, proper documentation, templates, etc. are huge. Have someone that just writes "Done." with nothing else in there as to what they did, how, versions, etc. is needing some serious training time.
lungbong@reddit
We use Jira for everything.
Initiatives - big ticket items, usually a project but we also have initiatives for EoL, security, capacity increases, upgrades etc.
Epics - defines a scope of work for an initiative to be done in at most a quarter, sometimes a sprint
Tasks - Multiple tasks make up an Epic, individual defined pieces of work. We normally maintain a massive backlog of tasks, which get broken down and fully defined each quarter. Tasks are normally IT driven work with a specific technical outcome and often solution e.g. upgrade router X, decom server Y.
Story - Similar to a task but usually business driven with a business outcome and solution isn't defined in the scope.
Sub tasks - Tasks/stories can be broken down further, e.g. where multiple people are needed to deliver the task/story.
Reactives - Unplanned urgent work - like patching Copy Fail
Incident - Something is broken and needs fixing
Problem - Something keeps causing incidents and needs fixing
Change - A record of what's been changed, when, why, how and and whom
Risk - A bad thing that might happen
Issue - A bad thing that has happened
Test tasks, bugs - Specific actions that can be off almost any type of ticket to test a piece of work and if it fails to record the bug
Support tickets - end user requests, biggest repeat requests will get catalogued and a task raised in the backlog to automate it
Sakkko@reddit
Not going to be a popular take but i set a Claude project with read/write access to our confluence space and everytime I take an action like you say more 'internal' I just tell it to Claude. It knows how to register it as a change log and it will stack multiple over a single day so there's one page per day instead of per change. I had this 'idea' after reading patch notes from a game i play that does weekly updates, so I thought why can't we have our own patch notes? So theres that.
AniBMagal@reddit
I have a customer called Internal. I track everything there. I do nothing without a ticket.
QuantumRiff@reddit
will not make ANY change to production with ticket detailing what/when/why. And for anything other than 'add more cpu to this instance' a backout plan.
MonoDede@reddit
If anything it makes it easier for yourself when you inevitably run into a similar task in the future. I've cursed my past self before for not explaining in detail the resolution to some issues after running into them again a year later. And I've been so grateful when I took the time to write things out and saved myself precious time.
QuantumRiff@reddit
Yep, we also make heavy use of confluence, and typically, after you write something new, a teammate goes through and replicates it, and clarifies the documentation for someone who hasn't just spent days analyzing a problem..
angrydeuce@reddit
This exactly. All time is tracked, even for something as stupid as power cycling a PoE port on a switch to restart a misbehaving AP or phone.
Our time has a dollar amount tied to it, regardless of where irs spent, and if youre not tracking that sort of stuff, youre only screwing the IT department over as a whole because thats part of how determinations are made regarding staffing levels.
Source: im one of the guys that has to pull those reports and punt them up the chain when I say "Seee! We do, in fact, need another tech...unless you feel like paying 30+ hours a week in OT, that is, since we are over our internal budget hours by that much".
cultvignette@reddit
This right here.
Internal ticket. Updated firmware. These devices, this version. Watch out for this. Time spent. Then, most importantly:
Here's who or what is responsible for why
CYA.
In a solo gig it's likely more a formality, but the more your tickets can hold up in court, so to speak, the better.
Tanto63@reddit
Yep! I do something similar but just have the ticket from me to me. Everything has a ticket.
hellobeforecrypto@reddit
Calendar or a ticket to yourself.
Jaereth@reddit
We actually use our ticketing system for a lot of it. If it's a good one you should have all the data you need right there. We just make separate queues from the user support ones and limit who can create tickets in it to admins only.
My ticket queue will show both user support tickets that have been escalated to me, monthly admin tasks, and one off parts of projects like your are suggesting. Nice to have it all in one place really.
DarthJarJar242@reddit
My first question is this:
What ticketing system do you currently use for customer generated tickets?
Based on that answer my suggestion is going to be a variation of what you have seen already. But I was going to give you a very broad look at what we do in our environment based on ServiceNow.
We have customer generated items that include:
Requests - things that aren't currently an issue but need to be implemented to prevent future problems.
Incidents - break/fix tickets
IT can generate all customer ticket types plus:
Projects - Basically the IT version of a Long term customer request.
Maintenance - Further broken down into Yearly/Monthly/Weekly/Daily types. These are generated either automatically by hooks into ServiceNow or by the technician as needed.
ChangeRequest - There are multiple versions of these change requests. Standard, Low Priority, Emergency, etc. Nothing is done in the production environment at a server/network level without a change request ticket logging all sub tickets, maintenance tickets, projects, incidents, etc. This is to cover ITs ass for when it inevitably happens that someone says "why did you do that?!?".
So for instance, you spoke directly about firmware upgrades. Let's say you have Fortinet Firewalls that get a critical vulnerability firmware update that HAS to happen. In our environment there would be a Change Request ticket created as an Emergency Change, a Project Ticket would be created, and then a maintenance ticket would be created for each Fortinet that needed to be updated. All of the maintenance tickets would be linked to the Project ticket and the Project ticket would be linked in the Emergency Change Request.
Previous-Low4715@reddit
There are loads of ticket types. Problems, incidents, requests, changes etc. ITIL will guide you on this
Aim_Fire_Ready@reddit (OP)
I guess I know what my next project is...you know, after the 12 I'm already working on.
mfinnigan@reddit
ITIL is mostly about learning vocab and common patterns that you could be using to manage IT
INSPECTOR99@reddit
lol, Yes, keep it as simple as your needs dictate. Perhaps your particular ticketing proggy has a hierarchy/directory structure that you can use to fine tune to your purpose.
jbldotexe@reddit
Look into CMDB and ITSM/ITIL
Wolfram_And_Hart@reddit
Your security stack should be doing some of it (Huntress is great) and otherwise change management tickets should be doing anything intentional.
gwig9@reddit
I have a documentation folder where I take screen shots and write down instructions for anything new I do. I also keep an "I love me" document where I write down a short synopsis of what I was asked for and keep any email requests flagged for the year. Makes all the difference when I go to write my performance review...
Normal_Choice9322@reddit
Wait for them to complain three more times
Half of them disappear
ProfessionalSea6268@reddit
Some are change requests (pre approved for things like updates but full changes for things like firewall firmware). But some (as has already been mentioned) would be “internal”.
lweinmunson@reddit
It's either a ticket or a change ticket. Normal tickets we break down into tasks, questions, and then incidents and problems. If it's an issue that affects multiple devices, it becomes a problem that incidents can be linked to.
So a firmware rollout would need a change ticket
DNS down is a problem that incidents can be linked to all of the incidents that come in. When the problem is closed, all of the linked incidents are closed.
I'll assign tasks to myself for internal tracking of building something new before I create a change ticket to put it on the network.
Questions are just the random junk.
toilet-breath@reddit
Don’t call me Shirley
Impossible_IT@reddit
Reminded me of this
hellofairygodmotha@reddit
I keep a “change log” basically a list of the change, who it effects, date I did it, screenshot, KB article to support the work if needed, category of change. Reason and description of the change. Not exactly a ticket but it’s a good place where I can keep track of all those changes. I’m sure a ticket works as well I really like my system it’s easy to sort through and it’s within my environment in case I ever changed ticketing systems.
For context, I am on a team of 2 so it works for us. May not work for everyone
VNDMG@reddit
Ceeate “operational” tickets
aguynamedbrand@reddit
If you are not creating a ticket then the work never happened.
GullibleDetective@reddit
Within a ticket
fuzzylogic_y2k@reddit
You can track them as tickets. Change order, commission/decommission, update. Make them work like quick notes that silent close and need as little input as possible.
Though you could skip these and opt for updating documentation. Like firmware spreadsheet and network diagram. Or notes in an asset management system.
EmperorGeek@reddit
We use an ITIL system (ServiceNow) and everything becomes a record in the system. Requests, incidents, Changes, Projects, Tasks, etc. all hardware is in the database and can be referenced in the tickets.
Soggy-Attempt@reddit
Do everything through a ticket.
roboto404@reddit
We have Internal Tickets in ServiceNow thats where I usually throw in stuff like that
cdm014@reddit
If they're not a support ticket, they're not events. Updates needed - ticket gets made to do updates. Config change - ticket. Pretty much anything that requires more than speaking - (say it with me) TTTIIICCCKKKEEETTT.
Tickets are your friends in both big and small orgs
pakman82@reddit
everything is a ticket, so everything is quantifiable. I am tempted to make my facilities use tracked that way. ... its sometimes the only way to get recognition.
D3moknight@reddit
What you are describing sounds like Change Requests.
M4niac81@reddit
ITSM system with change management.
Fit_Indication_2529@reddit
Yes, this is basically "standard work" in a mature IT environment. Not every internal IT action needs to be a user-facing support ticket, but firmware updates, configuration changes, maintenance work, and other noteworthy admin actions should usually be recorded somewhere. Depending on the org, that might be a change record, an internal ticket, a maintenance log, an SOP checklist, or a formal change-management process.The important part is that there is an audit trail: what changed, who changed it, when it changed, why it changed, and what the rollback plan was if something went sideways. This also builds a knowledge base of how to change things and what systems are dependant on what.
darkrhyes@reddit
Microsoft Planner or Microsoft OneNote or Evernote or SharePoint document library or, as someone said, a custom ticket customer. I have used the first few but it is hard in a shared environment where the text is editable. Hope you find a great solution!
FarmboyJustice@reddit
There are many ways to handle this. As many have said, you can just create helpdesk tickets for everything, but that works best if you've got a ticketing system that is designed to cover more than just helpdesk issues, otherwise you run into having to do a bunch of customization or manual workarounds for things that don't fit the "helpdesk" definition.
A good inventory management platform will provide a way to track and monitor these kinds of changes, and in some cases even automate them.
A simple checklist that you review on a schedule might even be enough.
Titanium125@reddit
You create a ticket for everything. Problem solved. Unless you’re paying your PSA vendor by the ticket of course(:
karlsmission@reddit
My team does not do work without a ticket. If we generate our own tickets for work or they come from external, there is always a ticket. Period.
Velvet_Samurai@reddit
Just create a ticket with yourself as the user. I do this all the time.
AUSSIExELITE@reddit
Outside of our main ticket board, I have a secondary ticket queue only visible to me and my team in Jira that we do all of our “non ticketed” work. This queue has no metrics, SLA or anything and literally only exists to keep track of stuff that needs to be done.
When I worked solo (and do still for personal stuff), I used TickTick dor the same thing mainly because side it’s the calendar for my life and I find it very quick and easy to add new tasks and schedule them if required.
Commercial_Growth343@reddit
You seem to be describing Change Management. We have a change control ticket system for that. There is also something called Problem Management which is the ticketing system used to manage Problems. These are industry standard terms, that I usually refer to ITIL but there are other systems like COBIT etc.
SysAdminDennyBob@reddit
Incidents - day to day support issues
Tasks - generic item for tracking something that needs to be done
Changes - Modifying a specific thing at a specific time
Major incidents - wide spread critical incidents.
Requests - hardware and software allocation
etc.... we have lots of different items that are tracked, some are even done in different toolsets. Most of these are standard out-of-box parts of your ITIL suite. e.g. ServiceNow
n1celydone@reddit
Some kind of Project tracker, anything that isn't a ticket gets logged there, we use azure devops
Aim_Fire_Ready@reddit (OP)
We have a ticket system but we also use Asana for projects, so I can use that for planned work or ones with bigger scopes. No reason I can't link one to the other also, I suppose.
mrbiggbrain@reddit
Everything is a ticket. If I need to do Firmware updates on some servers then I put in a ticket for that task. If I need to upgrade a software version, ticket.
Kanibalector@reddit
Everything is a ticket.
Automatic_Mulberry@reddit
In theory, there is some kind of ticket for every IT event. If it happens, there's some flavor of ticket. It's a break-fix, or a change request, or a work request, or a root cause investigation, or a bugfix, or a feature request...
Any kind of action should have documentation, and the initial paperwork gets filed before the work begins.
Of course, this goes out the window to some degree when one's boss calls and says "senior boss needs this done today, make it happen."
sharpied79@reddit
Back in the day (going back 25 years ago) our Remedy system had two "sides" with tickets on both:
Both had differing SLA's
We managed everything through it, even projects (to a degree, they were classed as change requests)
Everything in IT absolutely can be managed through a helpdesk/ticket system.
OregonTechHead@reddit
1) Is this planned? If yes, is it a project? If yes, create a project plan and documentation. If it's not a project, create a task to document and manage.
2) Is this unplanned? If yes, create an internal support ticket. ie backup job failed.
IMO, everything should have an associated ticket, task, or project for ease of documentation, tracking, and historical evidence.
npsage@reddit
Change ticket.
Some tools support it a native thing as a separate ticket type, sometimes you have to create a ticket but not it’s for XYZ.
apandaze@reddit
Change control - its like a ticket but with some project planning involved. Its used to track what is changed, plan if the change fails & also used for approval if needed.