Operations | Monitoring | ITSM | DevOps | Cloud

Great Lighthouse scores, but your site is still slow. Sound familiar? You’ve run PageSpeed Insights, Request Metrics, and every other synthetic test you can find. Your scores look great. But your analytics shows users bouncing, conversions dropping, and complaints about “slow pages.” What’s going on? The answer is simple: synthetic testing only tells you how your site performs in a test, not how it performs for real users in the real world.

Kubernetes has become the de facto platform for orchestrating containers. Open standards complement Kubernetes by defining best practices for its implementation. These standards are developed by the open-source Kubernetes community (not a single vendor), ensuring vendor neutrality, easier integration with other tools, and overall system efficiency.

Evidence of broad and sustained attacks using several npm, Python, and Ruby packages continues to emerge. A series of malicious packages have been added to the npm, PyPI, and RubyGems package repositories. The attacks have been ongoing for some time, with some seeded years ago. Their aims are manifold, including stealing funds from crypto wallets, deleting codebases, and obtaining Telegram messaging data.

We recently had the privilege of hosting several industry experts and technology executives across platform strategy, SRE, and engineering enablement for breakfast at our Observability Day in London. We noted that they’re all facing the same fundamental tension: deliver faster, scale smarter, stay resilient, and somehow get ahead of what’s coming next. But how do you move fast without breaking things? And how do you prove the value of the things you don’t break?

Software supply chain security has become a top concern for developers, DevOps engineers, and IT leaders. High-profile breaches and dependency compromises have shown that open source components can introduce risk if not properly vetted and maintained. Although containerization has become commonplace in contemporary development and deployment, it can have drawbacks in terms of reproducibility and security.

A recent LinkedIn poll by Peter Zaitsev asked: “What is the most common preventable cause of downtime in your environment?” Guess what most respondents said it was? Surprise, surprise – the top answer is Deploying Broken Code, with 57% of respondents selecting it. This reinforces how critical it is to catch issues before they hit production.

First of all, by frontend memory usage I mean the amount of memory that a user’s browser needs when using your website or webapp. Secondly, do you have any idea how much browser memory your website or webapp requires? Or do you know if or how much the memory footprint of your website/webapp has changed over the last few months? Or after the recent changes or releases you made? I’m guessing you don’t. Yet, this is important to monitor to avoid a bad user experience.

Observability and monitoring are the cornerstone of resilient, high-performing applications. Nearly every IT or software engineering leader we come into contact with emphasizes the importance of the ability to understand and diagnose what is going on with their applications at all times. Having clear and concise visibility into your applications is no longer optional.

Picture this: a crime scene where the evidence is scattered across five different rooms. There’s a footprint in one, a shattered window in another, a stray shoe on the stairs, and a witness across the street, who only saw part of what happened. Each clue matters in solving the case, but none of them tells the full story on their own.

Prometheus can be lightweight to start with, but once it’s in production, storage usage tends to grow faster than expected. Managing how long data is kept becomes critical, especially when you're working with limited disk space or tight budgets. This guide outlines the key concepts behind Prometheus data retention, how to configure it effectively, and what to watch out for.