Why Alerts Should Become Tickets, Sometimes

Tuesday, 07:40, at Redbrook Engineering. Omar is first in. The wall screen in the corner of the IT office shows twelve tiles, and three of them are red. One reads "Backup: design-share FAILED" and, according to the small timestamp under it, has been red since Friday at 23:10. Four technicians walked past that screen on Monday. Omar asks the room as it fills up. "I thought Dana had it." "I assumed Omar was on it, he does backups." "I saw it, I was going to mention it." The tile has been red for fifty-six hours. Nobody has touched the backup. Nobody did anything wrong. The screen asked the room. Rooms do not answer.

A monitoring system is software that watches servers, network devices and services and raises an alert when a measurement crosses a line somebody drew. That might be a disk fuller than a threshold, a service that stopped answering, a backup that did not finish. A dashboard is the screen that shows the current state of every alert at once, usually as coloured tiles. A ticket, in the sense this library uses throughout, is a record of one piece of work with an owner, a status and a history. This article is about when an alert should become a ticket and when it should stay on the screen. It is part of our Monitoring-to-Ticket Integration series, which covers the whole path from an alert firing to a ticket closing.

It covers what a ticket gives an alert that a dashboard cannot; what every ticket costs the desk; the three kinds of alert. Next come the four questions that decide and what belongs on the dashboard alone. Then come the alert that is also a major incident, whether alert tickets share the humans' queue, and how to start with five alerts. A short war story and the alert-to-ticket decision table to copy follow, in that order.

What a Ticket Gives an Alert

A ticket gives an alert an owner, and an alert has none. The dashboard shows the red tile to everyone in the room and assigns it to nobody. That is how Redbrook's backup went untouched for two days while four competent people looked at it. A ticket is claimed, by one named person, and from that moment the question "who has this?" has an answer. Claiming means a technician takes a ticket out of the shared pool and puts their own name on it, so that everyone else can stop wondering. The red tile could sit there until the screen burned in. The ticket will show up in Dana's list until Dana does something about it.

A ticket gives an alert a history, and a dashboard has only a present. When the backup finally runs, the tile goes green and the dashboard forgets that it was ever red. Nobody will find, in three months, that the same job failed on four Fridays, because the screen has no three months. The ticket does. A closed ticket with the job name in the subject is a record that can be counted. Four of them in a quarter is the pattern that finding the repeat tickets is built to catch. The wall screen is a truthful witness with no memory and no opinion about whose job it is.

A ticket gives an alert a status and a clock. It can be open, in progress, waiting on a part, or resolved. It can have a due time and go overdue. It can be escalated when the first person cannot fix it, and the escalation can be seen by the lead. It can appear in a report beside the human tickets. That way, the month's work on infrastructure is counted alongside the month's work on printers. None of that exists for a tile. A tile is red or it is not.

What a Ticket Costs

Every ticket is a demand on the desk's attention, and attention is the scarcest thing a small desk has. A ticket must be read, judged, claimed, worked and closed, and the cheapest of those steps still takes a person a minute. Ten alert tickets a day is nearly an hour of handling before anyone fixes anything. That is the cost when every one of them deserved to exist. The queue is a shared budget. Alert tickets spend it like anybody else.

Noise is worse than cost, because noise teaches the desk to ignore the queue. An alert ticket that nobody needs to act on arrives, is glanced at, and is closed with a sigh. Then another. By the end of the month the team has learned, without anyone deciding it, that anything with "monitoring" in the subject can wait. The one alert that mattered, the backup that really did fail, arrives in the same clothes and waits with the rest. The desk did not become careless. It was trained.

The test for whether an alert deserves a ticket is therefore simple to state. Would a competent technician, reading this alert on the screen, have opened a ticket for it by hand? If yes, the integration should do it for them, faster and without forgetting. If no, the integration should not do it either, however easy the setting is to turn on. The robot is allowed to be exactly as diligent as a good technician. It is not allowed to be more enthusiastic.

Three Kinds of Alert

Alerts come in three kinds, and only one of them always earns a ticket. An actionable alert says that a person must do something the system will not do for itself. A service has stopped and will not restart on its own. A backup failed and must be rerun. A disk is nearly full and nothing is scheduled to clean it. An informational alert says that something happened and nobody needs to act. A scheduled reboot completed, a failover worked as designed, or a job finished late but finished. A predictive alert says that something will cross a line if nothing changes. A disk will fill in three weeks at the current rate. A certificate expires in a month. A battery has reached the age at which batteries are replaced.

The actionable alert always becomes a ticket, because somebody has to own the action and the ticket is where owners live. The informational alert never does, because a ticket with nothing to do in it is a ticket that teaches the desk to close without reading. It belongs in a log, or in a weekly digest that somebody skims with coffee, or nowhere. The predictive alert earns a ticket when the response is work that a person must schedule. In that case, the ticket's due date is the thing that makes it useful. Fixing something before it becomes an outage is its own discipline, covered in fixing before the ticket. The monitoring integration is one of the ways the signal reaches the desk.

Most monitoring systems do not label alerts this way. And the labels they do use, "critical", "warning", "info", describe how loud the alert is, not whether it needs a hand. A critical alert about a service that restarts itself in ten seconds is loud and informational. A warning about a certificate that expires in a month is quiet and actionable. Sort by what the desk must do, not by the colour the monitoring system picked.

The Four Questions

Four questions decide whether an alert becomes a ticket. They are asked once per alert type, when the integration is set up, not once per alert at three in the morning. The first is whether a person needs to do something. If the system heals itself, by restarting the service or failing over to the second node, the alert is a record of a thing that worked. The second is whether it will still matter in an hour. A host that missed one check and answered the next, a login that failed once, a link that dropped for thirty seconds: these clear before anyone could read the ticket. A ticket that is resolved before it is read is pure cost.

The third question is whether anyone will need to know later that it happened. Some alerts need no action and still need a record. The audit will ask, or the count of them is the evidence for replacing the thing. Or the vendor conversation next month depends on knowing how often the link dropped. A record is not the same as a ticket, though; a log line or a digest is a record. The fourth question is whether the response has a deadline. "Renew the certificate by the twentieth" is work with a date. A ticket with a due date is the only container on the desk that will nag anyone about the twentieth. The dashboard has no concept of Friday.

• Does a person need to do something the system will not do itself?
• Will it still matter in an hour, or will it have cleared before anyone reads it?
• Will anyone need to know later that it happened, and is a log enough for that?
• Does the response have a deadline that somebody must be reminded of?

Read the answers together. Yes to the first question is a ticket, whatever the others say. Yes only to the third is a log entry or a digest line. Yes to the fourth is a ticket with a due date, even when the first answer is "not yet". No to all four is an alert that should probably not exist, which is a finding worth taking back to whoever owns the monitoring system. (They will tell you it was there when they arrived. It usually was.)

What Stays on the Dashboard

The dashboard keeps everything that describes a state rather than demanding an act. A processor at seventy percent is a number, and numbers are what dashboards are for. A service that restarted itself and recovered is a state that has already returned to normal. A device inside a planned maintenance window is a state that everyone already knows about. In each case the right thing for a technician to do on seeing it is nothing. A ticket whose correct handling is nothing should not have been raised.

The dashboard also keeps the alert that nobody on the desk can act on. The provider's internet link is slow; a vendor's hosted service is degraded and says so on its own page. A building's power flickered and the batteries carried it. The desk cannot fix any of these. And a ticket with no possible action is a ticket that will be closed with "nothing we can do", which is a note nobody wants to write twice. The honest edge here is the record. If the provider conversation next month needs a count of the slow afternoons, open a ticket for the pattern, once. Attach the counts to it, rather than opening one ticket per afternoon.

Keep the distinction plain for the team. The dashboard says what is true right now. The queue says who is doing what, by when. A thing can be on both, and a ticket that was opened from an alert is still shown as a red tile until it clears. But a thing that is only ever a state belongs on the screen and nowhere else. And a thing that needs a pair of hands belongs in the queue, where hands are kept.

The Alert That Is Also an Incident

Some alerts are the first sign of a major incident, and those get a ticket for a different reason. When the main file server stops answering, or the link to the warehouse drops at eight in the morning, the alert ticket is not the response. It is the record of the response. The work happens in a call, in the server room and in a flurry of messages. Somebody must still be writing down what was tried and when. That is because the review afterwards will need it and nobody's memory will supply it. The ticket is that somebody.

Do not let the integration decide alone that an alert is a major incident. The monitoring system knows a service is down. It does not know that payroll runs today, that the building is empty, or that this is the third time this week. A person declares the incident, by the test in what makes an incident major, and the alert ticket becomes the incident's record when they do. In practice the alert opens the ticket at ordinary priority. The first technician reads it and raises it. The robot rings the bell. The human decides whether it is a fire.

Where an incident spawns a dozen user tickets ("I cannot open the drawing folder", twelve times), the alert ticket is the one they all link to. That way, the dozen are closed together when the server comes back and the record of the cause lives in one place. Most tools can link or merge tickets; the alert ticket, which arrived first and names the actual device, is the right parent.

One Queue or Two

Alert tickets can land in the same queue as human requests or in a queue of their own, and both choices have a cost. A separate monitoring queue keeps robots away from people, which the technicians will like. It is also a place nobody looks on a busy afternoon. That is the first of the drawers described in keeping tickets from hiding. The same queue keeps every alert in front of whoever is triaging, which is the point. It also means a flood of alerts can bury a user's request under forty tickets about one switch.

My opinion, for a desk of one to ten people, is the same queue with a visible marker. Put a fixed prefix on the subject, something like "[ALERT]" followed by the device name, so that the eye sorts them in a glance. Route them to the department that owns infrastructure if your desk has more than one department. Some tools put every door—the web form, the mailbox, the chat and the REST API—into the same kind of ticket in the same queue. QuerySolv does this. In such a tool, the alert ticket sits beside the printer ticket and is claimed the same way. What you add is the marker that tells them apart. A separate queue is right only when a separate team owns the infrastructure and reads that queue as their main one.

Whatever you choose, make sure the alert tickets are in a view somebody reads every day. Make sure the view's owner knows the alert tickets are theirs to triage. A queue that nobody has been told to read is where red tiles go to retire.

Start With Five Alerts

Connect five alert types first, not fifty, and choose the five by pain. Ask the team which red tile has cost the desk most in the last few months, and listen for the stories. There is the backup nobody noticed or the disk that filled during a month-end run. There is the certificate that expired on a weekend or the battery that was flat when the power went. Those are the alerts that a competent technician would have opened a ticket for by hand and did not, because nobody was looking at the right moment. They are the integration's first job.

A typical first five, for an ordinary small organisation, starts with a backup job that failed. Then comes a service down on a server that users touch directly. Next is a disk above its threshold on a server, with no automatic cleanup. A certificate inside its renewal window and the uninterruptible power supply on battery complete the set. Each of these is actionable. Each has a clear owner. And each clears in a way the monitoring system can see, which matters for closing the ticket later. Start them on the simplest route, usually the monitoring system sending an e-mail to the desk's own address. And watch for a month before adding anything. The mechanics of the routes, and the key that stops one alert making ten tickets, are in opening tickets from alerts.

Do not connect everything on the first afternoon. Not even with the volume turned down. Not even "just to see what comes through". A desk that connects every alert at once learns within a week what a flood looks like. What a flood teaches, and the controls that stop one, are the subject of the floods article later in this series. Five alerts, one month, then the next five. The integration will still be there in the spring. So, if you go slowly, will the team's willingness to read it.

A Short War Story: The Amber Tile at Tollgate Foods

Tollgate Foods ran a dashboard in the depot office that showed, among forty other tiles, a certificate-expiry warning for the supplier ordering portal. The warning turned amber at thirty days to go and red at seven. Marta, the depot's one technician, saw it amber in the first week and meant to raise it with the portal vendor. Marta then spent three weeks on a warehouse scanner rollout. Meanwhile, the tile sat there being amber at a room that had other things to look at. The certificate expired on a Saturday night. The portal refused every connection on Monday morning. Fourteen depot staff keyed the day's supplier orders by telephone and spreadsheet until the vendor reissued the certificate at half past one. That was roughly fifty staff-hours for a renewal that took twenty minutes once somebody asked for it. The review found that the alert had been correct, visible and continuous for thirty days, and that at no point had it been anyone's. Tollgate made the certificate warning open a ticket with a due date two weeks before expiry, assigned to Marta by name. The following year's renewal happened on a Tuesday afternoon with nobody noticing. An alert on a screen is a notice; an alert in a ticket is a job, and only one of those gets done.

The Alert-to-Ticket Decision Table

The table below is the four questions applied to the alerts most small desks have, with the decision in the last column. Copy it, replace the rows with your own alert types, and fill the three middle columns honestly for each one before you connect it. A row whose decision reads "ticket" goes on to the mechanics article; a row whose decision reads "dashboard" is left on the screen. And the fact that it was considered and left is written down so nobody asks again in a month. The table is a one-time exercise per alert type, revisited at the monthly review, and it is deliberately short on nuance. Nuance is what the technician adds after the ticket exists.

Two rows earn a second look. "Power supply on battery" is actionable and usually clears by itself when the mains return. That is why the decision says a person confirms the close. The alert clearing does not tell you whether the battery is now flat. "Provider link slow" is the honest edge from earlier in this article. It needs no action, has no self-clearing, and has a record that may matter. So it gets one ticket for the pattern rather than one per afternoon. Everything else in the table is the four questions answered plainly. A desk that fills in its own rows the same way will have made the only decision that this article asks of it. The robot does the rest, and the robot, unlike the room, answers when asked.

Frequently Asked Questions