A departure board at Tyne and Wear Metro froze, and the world found out the way the world always finds out: a passenger took a photo. Behind the still-visible train times sat an elderly Windows error dialog — the board's Java application had crashed, a modal error dialog had appeared on the desktop, and the last-rendered frame stayed on screen as if nothing was wrong. No alert fired. No ticket was opened. The first incident notification arrived via social media and The Register, not via a monitoring console.
If you run a help desk, an internal IT department, or an MSP NOC, you already know this story. You just know it with different props: the lobby digital signage, the reception kiosk, the warehouse scanner terminal, the shop-floor HMI, that one legacy Java app finance cannot live without. The scenery changes; the failure mode is identical.
What Actually Happened — and Why It Is Everyone's Problem
A long-running Java application on a Windows machine died, and it failed politely instead of loudly. The app stopped repainting, a dialog demanded attention from nobody, and the display kept showing departure times that had been stale for who knows how long. From across the concourse the board looked operational. Up close, a Windows dialog was sitting on a dead application.
The uncomfortable part is not that Java crashed. Java crashes. The uncomfortable part is the entire detection chain that was missing:
- Nothing was monitoring the application process itself.
- Nothing was watching for a hung or unresponsive window.
- No alert existed, so no ticket could be created.
- The first human with both knowledge of the failure and the ability to report it was a commuter with a smartphone.
Swap departure board for any screen or appliance in your environment that someone deployed once and nobody has touched since, and you have this exact incident sitting in wait.
The Problem in Depth: Your Helpdesk Only Knows What Users Tell It
Reactive ticketing makes end users your monitoring system
Most helpdesk platforms — ConnectWise Manage, ServiceNow, Jira Service Management, HaloPSA, or a well-run email-to-ticket mailbox — share one architectural assumption: they wait. A ticket is born when a human notices a problem and reports it. Everything that happens before that first report is invisible to your SLA clock, your MTTR metrics, and your staffing decisions.
Run the math on a typical incident. The board's app dies at 06:50, before the morning rush. The first ticket lands at 08:35 from a commuter. A tech triages at 08:50, remote access fails because the box is a build nobody has a password for, and someone is dispatched to site. The board is back at 10:00. Your helpdesk report says MTTR: 85 minutes. Reality: the service was dead for 3 hours and 10 minutes, and 105 of those minutes are missing from every report you will ever show management. Detection time is the single largest and least-measured component of downtime in most IT organizations.
Monitoring that checks the wrong things
Some teams do monitor these devices — badly. Ping monitor: green. RDP port check: green. SNMP uptime: green. Meanwhile, inside that healthy Windows machine, the Java process is a zombie. This is the blind spot of machine-level monitoring in tools like PRTG, Zabbix, or a stock SolarWinds template: they verify the computer is alive, not that the workload on it is doing its job.
Java applications are the worst offenders, and every sysadmin who has supported one knows the failure catalog: heap leaks that take five days to reach OutOfMemoryError, AWT event threads that hang while the process idles at 0% CPU, and modal error dialogs that exist only in the interactive session — invisible to any service-level or network-level check ever written.
The forgotten endpoint class
Signage players, kiosks, and line-of-business Java apps fall between every ownership boundary you have:
- Not servers, so they miss per-server monitoring licensing and change control.
- Not standard workstations, so imaging, patch rings, and compliance scans skip them.
- Not in the CMDB, so when someone asks which box drives the board, the answer is a shrug and an RDP sweep.
At MSPs the gap is even more defensible-sounding: that is the client's signage vendor's appliance. Right up until it fails, the client blames you, and you have no agent, no history, and no remote access to prove where the fault lay.
Tool sprawl guarantees the gap
The average IT team runs monitoring in PRTG or Zabbix, ticketing in ConnectWise or ServiceNow, remote access in ScreenConnect or NinjaOne, and patching in WSUS — four or five tools that do not talk to each other. An alert in the monitoring tool creates nothing in the helpdesk. Bridging them requires a human to copy and paste, and humans are busy, so alerts die in dashboards and tickets start with users. That is the MSP tech with 12 tabs across 5 tools to support one client. That is the 2 a.m. page asking 'is it down?' that a two-dollar process check would have answered.
What it costs
- Detection gap: 30 to 150 minutes of silent downtime per incident, invisible in every report.
- Ticket noise: 15 users report the same frozen board, creating 15 tickets and three duplicate triage efforts.
- SLA fiction: the clock starts at first user contact, so reports flatter you while users suffer.
- Morale: technicians firefight instead of fix, and every incident starts with a complaint instead of a head start.
- Reputation: public displays are the shop window of the organization. Tyne and Wear Metro's failure was photographed, shared, and covered by the tech press before a technician knew it happened.
How AlertMonitor Closes the Gap
Monitor the application, not just the machine
AlertMonitor's agent-based monitoring goes below the operating system's heartbeat: is the process running, is its window responding, what is the memory trend, when did it last check in. The hung-Java scenario that ping cannot see fires an alert within one check cycle. And because AlertMonitor is a unified platform, those checks cover every Windows endpoint you deploy an agent to — servers, workstations, and that forgotten signage box alike, with no per-device-class licensing games that tempt you to exclude the cheap machines.
The alert opens the ticket — automatically, before the phone rings
This is the core of AlertMonitor's helpdesk integration: when a monitored alert fires, a ticket is created automatically and assigned based on the device, client, and alert type. A hung application process on a public-facing display at a busy site becomes a high-priority ticket in the right queue in seconds. End users never become your detection layer, because detection happened first.
Context-rich tickets mean the tech arrives knowing the answer
The auto-created ticket is not an empty subject line. It carries the full alert history for that device, current health data, and the memory graph that shows the leak building over six days. One click from the ticket opens a remote session. The tech does not ask which machine, does not hunt for credentials, does not drive to site to power-cycle anything.
The workflow, side by side
Old way: passenger photographs board → photo spreads online → email reaches the helpdesk at 08:35 → ticket is written → nobody knows which machine drives the board → RDP sweep → site visit → power cycle → three hours gone → no root cause recorded.
AlertMonitor way: process heartbeat fails at 07:42 → alert fires at 07:43 → ticket is auto-created and assigned at 07:43 → tech opens it at 07:45 with the full device history attached → one-click remote session at 07:47 → application service restarted and verified at 07:52 → ticket closed with a complete timeline and the leak graph attached for root-cause review.
Seven minutes, and the first to know was your tooling — not a commuter.
SLA data that survives an audit
Because the ticket is stamped at detection, MTTD and MTTR finally reflect reality. IT managers get real SLA reporting out of the platform — per queue, per client, per site — instead of stitching together a spreadsheet from monitoring exports and helpdesk CSVs. For MSPs, that means per-client SLA rollups across your entire book of business from one NOC dashboard.
Patching closes the loop
The phrase elderly Windows in the headline is doing a lot of work. AlertMonitor's patch management applies the same policy-driven compliance to these endpoints as to everything else, so the box running your departure board is not also the box missing two years of cumulative updates.
Practical Steps You Can Take Today
1. Find your forgotten Java endpoints
You cannot monitor what you do not know exists. Sweep the estate for machines running Java processes and rank them by process uptime:
# Find Windows machines running Java applications (signage, kiosks, LOB tools)
# and report how long each Java process has been running
$machines = Get-ADComputer -Filter 'OperatingSystem -like "*Windows*"' |
Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $machines -ScriptBlock {
Get-Process -Name java, javaw -ErrorAction SilentlyContinue |
Select-Object PSComputerName, Name, Id,
@{n='RunDays'; e={ if ($_.StartTime) { [int]((Get-Date) - $_.StartTime).TotalDays } }}
} -ErrorAction SilentlyContinue |
Sort-Object RunDays -Descending |
Format-Table -AutoSize
Anything showing 30+ RunDays is a hung-window incident waiting for an audience. Those are your first monitoring targets.
2. Check what ping cannot see: is the app actually alive?
Machine-up checks say nothing about the workload. This script verifies the process exists and its window is responsive:
# App-level health check for a GUI-based Java application
$proc = Get-Process -Name javaw -ErrorAction SilentlyContinue
if (-not $proc) {
Write-Output 'CRITICAL: application process not running'
exit 1
}
$hung = $proc | Where-Object { -not $_.Responding }
if ($hung) {
Write-Output 'CRITICAL: process running but window is NOT responding (hung)'
exit 1
}
Write-Output 'OK: application running and responding'
exit 0
The Responding property is the check that machine-level monitors cannot do — it detects the exact frozen-dialog state from the Metro incident. Deploy this as a scheduled check in AlertMonitor against every signage or kiosk machine you found in step 1.
3. Add safe auto-remediation for the known failure mode
Most of these incidents end the same way: someone restarts the app. Do it automatically, and escalate only when the restart fails:
# Restart the application service if the process is dead or hung
$service = 'DepartureBoardApp'
$proc = Get-Process -Name javaw -ErrorAction SilentlyContinue
if (-not $proc -or ($proc | Where-Object { -not $_.Responding })) {
Write-Output 'Unhealthy state detected - restarting service'
Restart-Service -Name $service -Force
Start-Sleep -Seconds 45
$check = Get-Process -Name javaw -ErrorAction SilentlyContinue
if ($check -and ($check | Where-Object Responding)) {
Write-Output 'RECOVERED: service restarted successfully'
exit 0
} else {
Write-Output 'ESCALATE: restart failed, manual intervention required'
exit 1
}
}
Write-Output 'HEALTHY: no action taken'
In AlertMonitor, exit code 1 fires an alert, the alert auto-creates a ticket with the script output attached, and the on-call tech sees the failure and the attempted recovery in one context-rich ticket. Self-heal when possible, ticket every time.
4. Wire the alert to the ticket by policy, not hope
In AlertMonitor: bind the health check to the device, set the alert type, and define the auto-ticket rule — device role public display means priority High, routed to that site's infrastructure queue. Add an escalation: unacknowledged after 15 minutes pages the on-call technician. Now the Metro scenario resolves itself in minutes, and if it cannot, a human is involved before a passenger notices.
5. Re-baseline your SLA reporting on detection time
Stop measuring from first user contact. With alert-to-ticket automation, the ticket timestamp is the detection timestamp, so your MTTD and MTTR finally measure the real outage. Review the numbers monthly per client or per site, and let the trend line — not a spreadsheet reconciliation — tell you where staffing and monitoring coverage need to go.
The Takeaway
Tyne and Wear Metro's departure board did not fail because Java is bad or Windows is old. It failed because a fragile application ran unwatched on a forgotten machine, and the first system with an opinion about the outage was a passenger with a phone. Every IT environment has those machines. Find them, monitor the workload rather than the hardware, let the alert open the ticket automatically, and hand the technician a context-rich ticket instead of a complaint. The photo on social media is optional.
Related Resources
AlertMonitor Helpdesk & End-User Support AlertMonitor Platform Overview Book a Demo Helpdesk & End-User Support Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.