Closing Tickets When the Alert Clears, and When Not To
Thursday, 14:20, at Northgate Retail. The till server at store 14 stopped answering at 13:58. The monitoring system opened a ticket, and Jonas claimed it at 14:01. At 14:03 the server answered again. The monitoring system sent its recovery message, and the integration resolved the ticket with the note "Alert cleared." Jonas saw the resolved notification, assumed the store had rebooted something, and went back to the laptop he was imaging. At 15:10 the store manager phoned. "The tills have been dropping out every twenty minutes all afternoon. Is anyone looking at it?" Jonas searched the queue. Nothing was open. Four tickets had been opened and resolved that afternoon, each alive for about five minutes, each closed by the same note. The alert had cleared four times. The problem had not cleared once.
When the measurement that raised an alert goes back under its line, the monitoring system sends a recovery, also called a clear. The integration has to decide what to do with the ticket it opened. Auto-close, or auto-resolve, is letting the integration mark the ticket resolved when the recovery arrives. Human confirmation is letting the recovery add a note and leaving the close to a person. Both are right for some alerts and wrong for others, and the choice is made once per alert type, not once per ticket at ten past three. This article is about that choice and the rules around it. It is part of our Monitoring-to-Ticket Integration series. It follows on from the mechanics of opening the ticket in the first place.
It covers what "cleared" actually means, then auto-resolve against human confirmation and how to decide per alert type. Next come the rule about never closing under a technician's hands, the alert that flaps, and the closing note that says what happened. We cover the ticket that should stay open after the alert clears, then reopening against opening a new ticket. We finish with a short war story and the auto-close rules to copy, in that order.
What "Cleared" Actually Means
A clear means that the measurement went back under the line, and nothing more. The disk is below the threshold. The service answered the last check. The host responded to a ping. The monitoring system reports this with the same confidence it reported the alert. And the word it uses, "recovered" or "OK" or "resolved", sounds like a verdict. It is a reading. Whether the thing is fixed is a separate question that the monitoring system has no way to answer, because it does not know what the problem was. It knows the number.
An alert clears for one of three reasons, and the integration cannot tell them apart. Someone fixed the cause: a technician restarted the service, freed the disk, replaced the drive. The cause fixed itself: the batch job finished and released the memory, or the network blip passed. Or the mains came back and the power supply went off battery. Or the condition moved without the cause changing. A log rotated and the disk dropped below the line for a day. Or the service restarted on a watchdog and will fall over again in an hour. Or the till server at store 14 answered one ping between the failures. The first is a close. The second is usually a close. The third is a trap with "OK" written on it.
Everything in this article follows from that. The clear is evidence, and usually good evidence, that the problem is gone. It is never proof. The rules below are about deciding, per alert type and in advance, how much proof the desk needs before a ticket disappears from the queue.
Auto-Resolve Against Human Confirmation
Auto-resolve is right when the clear is the fix, or as good as. A host that was unreachable and is reachable again is, for most purposes, back. A service that was down and is now answering is up. A disk that was above its line and is below it again has space, today. The recovery message and the thing a technician would check may be the same measurement. In that case, letting the integration resolve the ticket saves a person a click and keeps the queue honest about what is still wrong. It is also right when the cost of being wrong is small. If the alert comes back, the ticket comes back, and nothing was lost but a few minutes of a closed ticket.
Human confirmation is right when the clear does not prove the fix. A power supply going off battery tells you the mains returned; it does not tell you whether the battery is now flat. A storage array going from "degraded" to "rebuilding" is a change of state that the monitoring system may well call recovery. And it is nothing of the kind. A certificate alert clears when a new certificate is installed, and whether the application is actually using it is a thing a person checks in a browser. Human confirmation is also right for any alert type that is new to the integration and not yet understood. It is right for any alert whose ticket has a human requester linked to it who is waiting to hear. And, as the next section says, it is right for any ticket that a technician has already claimed.
Many tools keep a distinction between resolved and closed, with a window between them in which the ticket can come back cheaply. And that distinction is useful here. Let the integration mark the ticket resolved, which takes it out of the working queue. Let the tool's own confirmation window handle the return trip if the alert repeats. How that window works, and what it is for, is in resolved vs closed: the confirmation window. In some tools, a requester's reply reopens a resolved ticket, as it does in QuerySolv. In that case, a repeat alert that threads onto the resolved ticket as a reply from the monitoring address reopens it rather than opening a second. That is the behaviour you want inside the window. Test what your tool does with a message from the requester after resolution. Some reopen, some append silently, and some open a new ticket. The difference decides whether a flapping alert makes one ticket or ten.
| Alert type | Does the clear prove the fix? | Policy | Why |
|---|---|---|---|
| Host unreachable, now reachable | Mostly | Auto-resolve after a short clear delay | Reachable is what the technician would check |
| Service down, now answering | Mostly | Auto-resolve unless claimed | The restart may be a workaround; the technician decides |
| Disk above threshold, now below | Partly | Auto-resolve; note the margin | Space exists today; the growth may continue |
| Backup failed, next run succeeded | Partly | Human confirmation | The missed backup still happened |
| Power supply on battery, mains back | No | Human confirmation | Battery state unknown after the event |
| Storage degraded, now rebuilding or OK | No | Human confirmation | Rebuilding is not recovered |
| Certificate expiring, now renewed | No | Human confirmation | Installed is not the same as in use |
| Any alert type added in the last month | Unknown | Human confirmation until reviewed | You do not yet know how it clears |
Never Close Under a Technician's Hands
If a ticket has been claimed, the clear becomes a note and never a close, whatever the policy for that alert type says. The reason is that the technician is the one who made it clear, and they are not finished. Jonas restarts the service to see whether a restart helps. The service answers, and the recovery arrives. The ticket resolves itself and drops out of his list while he is still typing the note about what he saw in the log. Now his working notes are on a resolved ticket he has to go and find. The queue says nothing is wrong, and the cause he was about to look for has a quieter afternoon than it deserves.
The rule is cheap to implement on any route that can read the ticket before writing to it. If the ticket has an owner, append the clear as a note that says the alert recovered at this time, and stop. The owner closes it when they are satisfied, with their own note about what they found. On the e-mail route, the integration cannot read the ticket. The equivalent is to never auto-close at all for alert types that a person routinely works. On that route, accept that the clear is a note by default. This is less elegant and entirely safe.
The rule also protects the record. A ticket closed by the integration under a technician's hands has two authors who disagree about whether the work is done. The history shows the machine winning. Six months later, someone asks why the till server kept dropping that Thursday. The ticket says "Alert cleared" four times and nothing else, because the person who knew was never given the chance to write it down. The machine closes what the machine opened, and not what a person has picked up.
Remember: a clear is a measurement, not a verdict. Auto-resolve only where the clear proves the fix, never on a ticket a technician has claimed. Always include a note that says what cleared, when, and for how long it had been wrong.
The Alert That Flaps
A flapping alert is one whose condition crosses the line and comes back repeatedly. Examples are a disk hovering at the threshold as files are written and deleted, or a service that restarts itself every few minutes. Another is a link that drops and returns. Each crossing is an alert and each return is a clear. An integration that opens on alert and closes on clear produces a stream of five-minute tickets, which is exactly what store 14 produced. Nobody reads a five-minute ticket. The queue looks clean, the dashboard flickers, and the problem continues in the gap between the two.
Flapping is controlled at three layers, and the first is the monitoring system itself. Most monitoring systems can require a condition to persist for several consecutive checks before alerting. They can use a lower line for the clear than for the alert. That way, a disk that alerts at ninety percent does not clear until it is back under eighty-five. That second idea is called hysteresis, and you need the word only to find the setting. The plain version is "clear further down than you alert". Set both for anything that commonly flaps, and most of the stream never reaches the integration.
The second layer is the integration, and it has two controls. A clear delay waits for the condition to have been clear continuously for some minutes before resolving the ticket. That way, a one-ping recovery in the middle of an outage does not close anything. A flap counter watches for the same key alerting again inside a short window after its ticket was resolved. After the second time in an hour, say, it stops auto-resolving that key. Instead it reopens the ticket, raises its priority, and adds a note that reads "this alert has cleared and returned three times since 13:58; auto-close suspended; a person needs to look at this". That note is the one Jonas needed at 14:10, and it is a note the integration can write without knowing anything about tills.
The third layer is the desk. An alert that flaps is a problem in the sense that known errors and workarounds uses the word: a recurring fault with an unknown cause. The flapping ticket stays open, owned by a person, until the cause is found. The monitoring threshold or the check itself is adjusted as part of the fix. Flapping is a signal about the system or about the threshold, and either way it is information. The only wrong response is to let the integration keep tidying it away.
The Note That Says What Happened
"Alert cleared" is a note that says nothing, and a ticket closed with it is a ticket that will teach nobody anything later. The closing note the integration writes must say what cleared, at what time, and how long the condition had been true. It must say how many repeat alerts arrived in between and what the final reading was, with a link back to the alert. That is five facts, all of which the integration knows, and together they turn a closed ticket into a record. A technician reading it in six months learns that the disk was over its line for forty minutes on a Tuesday night. They also learn that the disk sent three repeats and dropped back to twelve percent free. That is enough to decide whether to care.
recovered: 14:38 condition held for: 40 minutes (since 13:58) repeat alerts while open: 3 final reading: 12 percent free closed by: integration, per the rule for this alert type link: the alert's page in the monitoring system
Write the integration's note as an internal note rather than a public reply. The requester on the ticket is the monitoring address and nobody is reading its mail. Where a human was involved, their note sits beside the integration's and says the part the machine cannot. It says what they found, what they did, and whether it is fixed or merely quiet. The shape of a note that is still useful in a year, and the three questions it answers, is in resolution notes worth reading later. An alert ticket deserves the same note as any other. And the integration can write half of it for you.
Keep the two notes distinct in the record, so that a reader can tell what the machine observed from what the person concluded. The integration's lines are facts about measurements. The technician's lines are judgement. A ticket history where those are mixed is a history where every line has to be read twice to know which kind it is. And most readers will not bother. (The second reader of any ticket history is a tired person with a different problem. Write for them.)
The Ticket That Should Stay Open
Some tickets must stay open after the alert clears, because the clear is not the end of the work. The clearest case is the workaround: the service was restarted, it is answering, and nobody knows why it stopped. The alert is gone; the fault is not. The ticket stays open, or is closed and a problem ticket opened and linked to it. But it does not simply vanish because a number went green. The same is true of a disk that cleared because someone deleted a log folder. The growth that filled it is still growing, and the ticket is the place where that gets said.
The second case is the clear that came from a change rather than a fix. A reboot clears almost every alert on a server for a few minutes, and a reboot during maintenance clears all of them at once. Neither tells you anything about Tuesday. If the clear arrives inside a maintenance window, or within minutes of a reboot, the integration should note it and leave the ticket open for a person. The third case is the one the table already flagged. It involves the power supply, the storage array, or the certificate. In those cases, the clear is a change of state that the monitoring system is happy with and a technician should not be.
The fourth case is the quietest and the most dangerous. An alert can clear because the monitoring system stopped checking. The check may have been disabled, or the device removed from monitoring. The agent on the server may have stopped, or the monitoring system itself gone down. Silence then looks exactly like recovery. An integration that closes on silence will close every ticket on the desk the night the monitoring server loses its disk. Do not treat silence as recovery. Not for a host, not for a service, not "just for the overnight ones". A clear is a message that says clear. The absence of a message says only that nobody is talking.
Reopen or Open a New Ticket
When the same alert returns after its ticket was resolved, the integration has to choose between reopening the old ticket and opening a new one. The right answer depends on how long it has been. Within a short window after the close, a return means the problem was never fixed. Reopening the same ticket keeps the history together and counts, honestly, as a reopen. After a long gap, a return is a fresh occurrence of a familiar problem, and a new ticket, linked to the old one, is the better record. The window is a judgement per alert type. A day is a reasonable default for most, longer for things like disks that fill slowly, shorter for things that are either up or down.
The choice matters because reopen counts are how a desk learns whether "resolved" meant fixed. A disk ticket that reopens three times in a week is a desk fixing the symptom three times. A service ticket that reopens every Monday is a problem with a schedule. Those patterns are visible only if the integration reopens inside the window rather than opening a new ticket each time. They are the signal that what a reopen is telling you is built on. An integration that always opens a new ticket makes the desk look busy and the fixes look permanent, and both impressions are false.
Whatever it does, the integration writes which it did, in one line. For example: "reopened: alert returned 50 minutes after close" or "new ticket; previous occurrence closed nine days ago, see ticket 4418". A reader should never have to work out from timestamps whether this is the same problem continuing or the same problem again. The integration knows. It should say.
A Short War Story: The Rebuilding Array at Stonebridge Insurance
At Stonebridge Insurance, the backup server's storage array raised a "degraded" alert when a drive failed on a Tuesday afternoon. The integration opened a ticket, and Faisal claimed it, found a spare, and swapped the drive within the hour. The array began rebuilding and reported its state as "rebuilding" rather than "degraded". And the monitoring system, which had been configured to treat anything that was not "degraded" or "failed" as healthy, sent a recovery. The integration auto-resolved every storage alert on recovery and had not been told to leave claimed tickets alone. It closed Faisal's ticket under his hands with the note "Alert cleared". Faisal saw the notification, assumed the rebuild had finished faster than expected, and went home. The rebuild failed at two in the morning when a second drive gave out under the load. The new alert opened a new ticket at ordinary priority with no link to the first. The new ticket was found at nine, by which time two nights of backups had not run. A claims file that an adjuster deleted on the Wednesday had to be reconstructed from e-mail over the following week. Stonebridge changed the storage alerts to human confirmation and added the rule that a claimed ticket is never auto-closed. It made "rebuilding" a warning state rather than a recovery. An alert clearing is the monitoring system reporting a number; whether the thing is fixed is a question for whoever swapped the drive. And the ticket should wait for their answer.
The Auto-Close Rules
The rules below are the one-page decision for every alert type the integration handles. Fill one block per type, before that type is allowed to auto-close anything. Keep the sheet beside the integration's record so that the next person can see why each choice was made. The first three sample blocks show the shape for a type that auto-closes, a type that needs a person, and a type that flaps. The blank block is the one you copy. The general rules at the bottom apply to every type and are not optional.
AUTO-CLOSE RULES — ONE BLOCK PER ALERT TYPE Alert type: host unreachable Clear proves fix? mostly Policy: auto-resolve Clear delay: 5 minutes of continuous clear before resolving Reopen window: 24 hours (a return inside it reopens the same ticket) Flap limit: 2 returns in 1 hour suspends auto-close and flags a person Note must contain: recovered at, condition held for, repeats, final state, link Alert type: storage array degraded Clear proves fix? no (rebuilding is not recovered) Policy: human confirmation Clear delay: not applicable; the clear is a note Reopen window: 7 days Flap limit: not applicable Note must contain: state change and time; technician confirms rebuild complete Alert type: disk above threshold Clear proves fix? partly Policy: auto-resolve, with hysteresis set in the monitoring system Clear delay: 30 minutes of continuous clear Reopen window: 3 days Flap limit: 2 returns in 24 hours suspends auto-close and opens a problem Note must contain: recovered at, held for, repeats, final percent free, link Alert type: ______________________________ Clear proves fix? [ ] yes [ ] mostly [ ] partly [ ] no Policy: [ ] auto-resolve [ ] human confirmation Clear delay: ______ minutes of continuous clear Reopen window: ______ (a return inside it reopens the same ticket) Flap limit: ______ returns in ______ suspends auto-close; flag ____________ Note must contain: recovered at, held for, repeats, final reading, link, ________ GENERAL RULES, EVERY TYPE [ ] A claimed ticket is never auto-closed; the clear becomes a note. [ ] A clear inside a maintenance window or within 15 minutes of a reboot is a note. [ ] Silence is not a clear; only a recovery message resolves anything. [ ] Every integration note is internal and states the time and the reading. [ ] Every new alert type runs on human confirmation for its first month.
Run the sheet against the till server at store 14 and the afternoon goes differently. The first clear waits five minutes and never arrives, because the server drops again at 14:07. The ticket stays open, and Jonas's claim holds it. And the third return inside the hour adds the line that says a person needs to look at this. One ticket, one owner, one afternoon of history, and a store manager who, when she phones at 15:10, is told that somebody already is.
Frequently Asked Questions
Should alert tickets auto-close at all?
What is a sensible clear delay?
How do we stop a flapping alert making a ticket every five minutes?
Should the integration's closing note be a public reply or an internal note?
If the alert comes back the next day, is that a reopen or a new ticket?
What if the monitoring system itself goes down? Will every ticket close?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.