As reported by NDR in mid-September, the Hamburg Public Prosecutor’s Office failed to send any electronic correspondence—approximately 17,000 messages—for two months. The systems were running, and none of the checks flagged the issue. It was first noticed by attorneys who were missing their mail. A mailing failure like this can happen in any organization that handles its work through specialized applications. With a different type of monitoring, it wouldn’t go unnoticed for weeks, but rather for minutes.
The Situation: One update, and the mail piles up
According to an NDR report dated September 15, 2026, a software update on July 9 halted the electronic mailing of correspondence. This also affected correspondence related to ongoing proceedings, such as requests to attorneys and notices of case dismissals. The *Hamburger Abendblatt* was the first to report on the incident. Following external reports, the agency had the error corrected and resent the letters; deadlines from that period are to be generously extended.
The public prosecutor’s office has announced that it will examine how such errors can be detected earlier in the future. This article addresses precisely that question. We are not familiar with the agency’s software from the inside, and we are not judging anyone. We are simply describing what we have observed in many projects and what has proven effective in those contexts.
The damage caused by such an error grows with every day that goes by without anyone noticing it. If a shipping hold is noticed after an hour, it affects a few dozen letters. After nine weeks, the number rises to thousands, along with missed deadlines, follow-up inquiries, and a lot of extra work for everyone involved.
Why the control group remained silent
Most IT monitoring systems essentially only check whether the technology is running. They verify whether servers are accessible, whether programs are running, and whether there is enough free disk space. After a failed update, all of these conditions still hold true. The application opens, employees work as usual, and documents are created. Only the final step—sending the documents—no longer takes place.
Errors of this kind are silent. A system crash is immediately noticeable because no one can continue working. A silent error, on the other hand, makes everything appear to be working normally while disrupting a single connection somewhere in the background. There is no error message and no red status indicator.
In monitoring, the absence of something is harder to detect than an error. An error message is an event to which a monitoring system can respond. Silence does not generate an event. To detect silence, one must first define what happens during normal operation and then notice when it is absent.
What should be observed instead: the result
The key is a shift in perspective. Monitoring is no longer just about whether the technology is working, but whether the application is delivering what it’s intended to do. In the case of a mailing system, that means the number of letters that are actually sent out. In technical terms, this is called functional monitoring, which refers to monitoring the outcome of the work.
The diagram illustrates the difference: Standard monitoring focuses on servers and applications, while technical monitoring focuses on sending and receiving.
flowchart LR
A[Server] --> B[Fachanwendung] --> C[Schreiben erstellt] --> D[Versand] --> E[Empfänger]
U([Übliche Überwachung]) -. prüft .-> A
U -. prüft .-> B
Z([Zählung versendeter Schreiben]) -. zählt .-> D
T([Testbrief an eigenes Postfach]) -. prüft Eingang .-> E
classDef luecke fill:#f8d7da,stroke:#b02a37,color:#000
classDef neu fill:#d1e7dd,stroke:#146c43,color:#000
class D luecke
class Z,T neuThis figure is already available in nearly every application—for example, in a shipping log or the outbox. It simply needs to be checked regularly and compared with normal operations. The business application itself does not need to be modified for this purpose. Only the quantities are recorded—no content, no case numbers, and no names.
With approximately 17,000 letters in about nine weeks, the volume amounts to several hundred letters per workday. A complete standstill is clearly evident at this volume. It can be reliably distinguished from a normal break within a quarter of an hour.
Five Steps to Prevent Unnoticed Shipping Failures
The first module alerts the system when operations come to a complete standstill. If not a single document is sent out for a quarter of an hour during business hours, the responsible team immediately receives a notification. At night, on weekends, and on holidays, this alert is disabled because nothing is sent out during those times even under normal operating conditions.
The second module reports a significant decline. Sometimes an error affects only one of several shipping routes, in which case the volume drops but does not fall to zero. The monitoring system therefore compares each hour with the same hour of the previous week and issues an alert if less than half the usual volume is shipped out.
The third module monitors the monitoring process. If the reading of the numbers itself fails, that should not be considered a sign of inactivity. Missing measurement values therefore trigger the same alert as a missing shipment. Otherwise, the same blind spot would arise, just one level deeper.
The fourth component is part of every update. The day after the update is deployed, the operations team compares the mailing volume with the volume prior to the change. This review is a fixed item on the checklist, along with documentation. The fifth step involves sending a regular test letter to the company’s own mailbox. This confirms that letters are not only being sent but are also being received.
What that would have meant in the Hamburg case
With these components in place, the mailing suspension on July 9 would have triggered an alert after a quarter of an hour of service at the latest. If the update had been installed outside of business hours, the alert would have been triggered shortly after the start of the workday the next morning. Instead of thousands of undelivered letters, there would have been only a few dozen. The timeline shows both trends on the same scale; the notification after a quarter of an hour is just a single point on it.
gantt
title Versandausfall ab 9. Juli ohne und mit Meldung
dateFormat YYYY-MM-DD
axisFormat %d.%m.
section Ohne Meldung
Schreiben bleiben liegen, rund 17.000 :crit, ohne, 2026-07-09, 2026-09-04
section Mit Meldung
Meldung nach 15 Minuten Dienstzeit :milestone, mit, 2026-07-09, 0dThe deadlines would have remained unchanged, and the legal profession would likely never have found out about the error. The follow-up work within the agency would also have been unnecessary. The update itself would have been just as flawed, but it would not have had any consequences.
The effort required is well worth it. Once it is clear where the number of letters sent can be found, the reports and an overview page can be created in just a few days. Experience shows that the bulk of the work involves jointly determining which figure truly reflects the results of the work.
What Those in Charge Should Keep in Mind
Implementation is technically straightforward, but organizationally it cannot be done haphazardly. Those in charge should clarify three points in advance. First, who receives the notification and is authorized to take action. Second, what the working hours are and who is responsible outside of those hours. Third, how proof of each update is documented.
In the case of government agencies, data protection is an additional consideration. The monitoring system described here relies exclusively on counter values and remains entirely within the agency’s own infrastructure or with its own IT service provider. No data leaves the agency, and no external service has access to its procedures.
The choice of tools is also important. For this type of monitoring, there are open, widely used standards that do not require a license tied to a single manufacturer. This simplifies procurement and ensures the solution remains operational even if the service provider changes.
How Lets Scale IT AG Can Help With This
We have been setting up these monitoring systems since 2019 for companies and public contracting authorities. For a government agency such as the Hamburg Public Prosecutor’s Office, we follow a three-step process. We begin with a brief meeting with the individuals responsible for the specialized application and the IT service provider. During this discussion, we determine where the number of sent letters can be tracked, what business hours apply, and who should receive notifications. This results in a written proposal outlining the scope, timeline, and fixed acceptance criteria.
In the second step, we’ll implement a pilot for a single shipping route. It includes notifications in the event of a stoppage or a significant decline, monitoring of the measurement itself, an overview page, and checks for updates. Acceptance will be based on a joint test: A simulated shipping stoppage must be reported within the agreed-upon time. If the pilot fails to meet an acceptance criterion, we will be responsible for the rework.
In the third step, we apply this approach to additional shipping channels and other specialized applications where a silent outage would have similar consequences. Everything runs on our own infrastructure or that of our IT service provider, using open standards and without any licensing restrictions. Finally, we hand over the solution to the operations team, complete with documentation. Throughout the entire project, the agency has a dedicated point of contact at our company.
Where this approach reaches its limits
Monitoring requires a system where outgoing mail can be tracked. If there is neither a log nor a system capable of analyzing outgoing mail, this system must first be set up, if necessary in collaboration with the software vendor. This may extend the implementation process by several weeks.
A count can also be misleading if it marks a letter as sent before it has actually been transported. In that case, it reports a shipment that never arrives. That is exactly what the test letter is intended for, though it does not replace the count. For very small mailing operations with only a few letters per day, comparing the numbers to the previous week is not meaningful; in such cases, the only option is to report a complete halt in operations over an extended period.
After all, a bug report doesn’t fix a bug. It just shortens the time it takes for someone to find out about it, and it’s no substitute for thorough testing before an update.
Conclusion: Monitor what the application is used for
The Hamburg case highlights a shortcoming that exists in many organizations. Monitoring checks whether the technology is running, but not whether the work is actually being done. A faulty update can happen to anyone, but two months of unnoticed downtime doesn’t have to.
Anyone who monitors the system’s output themselves, is notified immediately in the event of a stoppage, and compares results after every change can detect a shipping failure within minutes. The starting point is always the same question: What results must an application deliver every day, and how would you know if it fails to do so? Anyone who doesn’t have an answer to that today has found a gap before an update does.
To schedule an initial consultation regarding your specialized application, please contact us at lets-scale.it.