I used to prefer sending an extra alert to an experienced engineer rather than risk withholding something useful. The position sounded cautious, and in an individual case it could be reasonable. Applied broadly, it also became a way to leave the response question unresolved. The person on call received the signal and had to decide what it meant, whether someone was already acting and which consequence required attention. I had given the team more evidence without always giving it a better basis for action.
A review of one twenty-eight-day period made that cost visible. We counted 286 pages: 169 repeated an already open condition, 73 supplied no distinct immediate action and 44 led to a defined response. Those categories described the reviewed pages, not a count of separate incidents or failures prevented. The repeated and unclear messages still required human interpretation. I could no longer defend the total simply as proof that our monitoring was thorough. The service might be well observed while the route from observation to response remained poorly designed.
Count the task hidden inside the signal
A page asks a person to interrupt something and decide what to do next. That request should have a reason beyond the fact that a measurable condition changed. The team needs to understand the service consequence, whether the issue belongs to an existing response and which action or escalation is expected. If the condition is useful for later analysis but has no immediate task, it may belong in a different route. That is not a reason to discard the evidence. It is a reason to be deliberate about the kind of attention the evidence requires.
Service owners worried that reducing pages could hide deterioration. I agreed that simply raising thresholds until the channel became quieter would be an inadequate response. We retained the underlying telemetry and examined the rules with the people responsible for the service. Some signals were connected to an already open incident, some required scheduled review and others justified an immediate page. Each rule needed a named owner and an explanation of the expected response. The design had to account for the actual work, including escalation when the initial responder lacked authority or context.
The programme cost ₹29 lakh and used six weeks of engineering effort. Three reporting features were deferred. I kept those consequences in the decision because service-response work competes with other useful engineering work. It is tempting to describe a change in paging rules as housekeeping that ought to happen without an explicit resource choice. In practice, understanding the signals, testing the revised routes and preparing the response instructions took people whose time had already been assumed elsewhere. The company needed to accept that trade-off rather than expect the on-call team to fix the problem between interruptions.
My own earlier preference belonged in the explanation. The broad paging pattern was not only a habit inherited from unnamed engineers. I had supported it because I wanted experienced people to see everything that might matter. That intention did not settle whether the arrangement was effective. The review gave me evidence that the design needed to do more of the interpretive work before requesting immediate attention. A leader should be willing to revise a position that sounded responsible when its practical burden becomes clearer.
A quieter channel must not conceal a deteriorating service
A later twenty-eight-day observation produced 91 pages, 32 of which led to a defined response. The other 59 remained in the review. I did not announce that the lower total proved the service had become safer or that engineering productivity had improved by a calculated percentage. Workload and incident conditions differed between the periods. The observation was useful, but it was not a controlled experiment isolating the effect of the rule changes. A compelling before-and-after chart can invite a causal conclusion the evidence does not support.
We also kept the remaining unclear work visible. If every page that did not lead to an immediate action were automatically treated as a mistake, the team might suppress a signal whose value emerges only in context. The review needed to ask why the page was sent, what the responder learned and whether the route should change. The aim was a more useful request for attention, not a perfect-looking response ratio. An unexplained signal deserves examination; it should not be relabelled merely to improve the metric used to judge the programme.
Monitoring for conditions no longer sent immediately to a person continued through the agreed routes. That distinction mattered to service owners and to the CIO. Reducing the interruption channel did not mean deleting the underlying evidence or accepting an unknown deterioration. It meant assigning the signal to a response appropriate to its purpose. The company still needed people to review patterns, investigate recurring conditions and revise the rules when the service changed. A better paging design does not eliminate the continuing work of understanding the system.
I would be concerned by a programme whose success depended on the absence of complaints from the on-call team alone. People can become accustomed to a difficult arrangement or stop reporting a problem they believe will not be funded. Equally, a reduction in complaints does not establish that every important service condition is now visible. The account needs both operating evidence and a clear explanation of the response model. The people carrying the work should contribute to that explanation, without being made solely responsible for proving that the system needs improvement.
Treat the responder's work as part of the design
The lesson extends to other engineering choices. A receiver that correctly holds an event gap needs an investigation route. A restricted diagnostic stream needs a way for an authorised person to obtain further context. A certificate transition needs owners who can complete the participating integrations before the permitted window ends. In each case, the technical mechanism creates work for people. Calling the implementation complete while leaving that work unspecified transfers responsibility to the next shift and makes the design appear simpler than it really is.
I want those operating tasks considered before release. Who will act, what authority do they need and which evidence will tell them whether the action is complete? What happens when the ordinary route cannot resolve the condition? The answers need not turn every engineering document into an elaborate manual. They should make the consequential response usable by the person who will actually carry it out. The test should include that person or a realistic rehearsal, because the designer's familiarity can make an incomplete explanation look sufficient during a demonstration.
For directors, the useful question is whether management understands the work behind its service measures. A high alert count is not necessarily evidence of strong protection, and a low count is not necessarily evidence of neglect or improvement. What response do the signals require, what remains unclear and how is the organisation learning from the result? A board can ask those questions without designing an individual alert rule. It can also examine whether the resource needed for response quality has been made explicit alongside new-feature commitments.
I still prefer a defensible unnecessary page to a concealed serious condition. What I no longer accept is that this preference relieves us of designing a better distinction. Broad interruption can become a substitute for deciding what the signal means and who should act. The engineering responsibility is to make that decision as clear as the evidence allows, preserve the uncertainty that remains and fund the people who must respond. A page should be a considered request for action, not the place where an unfinished design hands its hardest question to someone at night.