Operations | Monitoring | ITSM | DevOps | Cloud

We are releasing Icinga TOTP Web v1.0.0, which adds Time-based One-Time Password (TOTP) two-factor authentication to Icinga Web.

An API latency spike hits your checkout service, and within ninety seconds your on-call phone won't stop buzzing. A CPU threshold breaches. A database connection pool exhausts. A pod restarts. An error rate crosses 5% on a downstream service. Six engineers get paged inside four minutes. Forty alerts. Seven services. One incident. Every monitoring tool in the stack is doing exactly what it was configured to do, telling you that something is wrong.

Modern applications can fail in many different ways, from performance regressions and frontend errors to systems that break under heavy load. Because no single testing or monitoring approach can catch every type of failure, effective reliability testing requires multiple layers that validate your application before, during, and after their release.

Your AI coding agent can refactor a module, write tests, and open a PR. It can read your codebase, understand your patterns, and suggest changes that follow your conventions. What it cannot do, unless you set it up, is see what is actually happening in production. That is a problem. The agent that writes the code should have access to the errors, traces, and performance data that code generates once it ships. Without production context, your agent is writing fixes based on the code alone.

Last updated: July 2026. Your AI feature works in development. It demos well. Then it hits production and you discover three problems your test suite did not catch: the LLM hallucinates product names that do not exist, the RAG retrieval step adds 4 seconds to every request, and your OpenAI bill is 3x what you budgeted because one prompt template is burning tokens on context that does not help the output. Traditional APM would have caught the latency.

When something breaks in a distributed system, "is it down?" is the easy question. "Why is it down, and where exactly?" is the one that actually costs engineering teams time. Observability is the practice and the tooling built to answer that second question, and it's become one of the most important disciplines in modern software operations.

Monitoring tells you when an event you predicted has actually happened. Observability lets you investigate behavior you may not have predicted at all. For most of the past decade, that distinction was something teams could afford to treat as a philosophical debate, because their systems failed in expected ways that had been seen before. A memory leak, a bad deploy, a saturated connection pool. You could build a dashboard and alerts for each and sleep reasonably well.

Every four years, workplaces around the world face the same dilemma. The World Cup kicks off, calendars mysteriously empty during match times, and IT teams brace for an invisible surge in traffic. Many employers try to block the streams and fight the inevitable. But what if the smarter business move is simply to accept reality? If your employees are going to watch the World Cup anyway, don't make them do it individually on their work laptops.