Operations | Monitoring | ITSM | DevOps | Cloud

The notifier has returned a message throughout this series, which made testing almost suspiciously easy. Assert on the return value and you are done. Real notifiers do more than build strings: they send them. Once a message goes to an email provider or SMS gateway, the function may return nothing useful. When that change lands, every existing test loses the value it asserted on. This is part 4 of a ten-part series. The code is in Java, Node.js, Go and Python.

Every codebase has a failure path nobody has run. Not through laziness, but because reproducing it requires a backend dependency to misbehave on cue. In the package notifier, the carrier must refuse, stall, or return nonsense at the exact moment the test runs. So the retry logic ships unverified and everyone hopes. The seam from post 2 already gives the test control. A seam is a place where you can change what code does without editing that code.

The spy from post 4 is a sharp tool. Once a test can record every interaction, it is tempting to assert on all of them. The result looks thorough, but it is usually a transcript rather than a useful specification. This post takes a test written that way, makes a change that no customer could possibly notice, and watches the test fail anyway. This is part 5 of a ten-part series. The code is in Java, Node.js, Go and Python.

August brought notable outages across developer platforms, SaaS tools, communications services, and cloud applications. StatusGator detected 789 Early Warning Signals during the month. Of those, 153 incidents (19.39%) were acknowledged by providers, while 636 (80.61%) were not officially acknowledged. StatusGator’s Early Warning Signals often surface service disruptions before providers post an official update.

An ITSM maturity model is a practical framework for measuring where your Service Management stands across people, processes, technology, and governance, then turning that baseline into a prioritized improvement plan. Most models describe five levels — from ad hoc to optimized — with clear characteristics and outcomes at each stage. This guide explains the levels, how to assess your current state, how to map capabilities to ITIL 4 practices, and actionable steps to get started.

Most growing teams eventually consolidate onto a full observability platform, and for teams correlating logs, metrics, and traces across a complex system, that’s often the right call. But a dedicated log tool still wins for a specific set of teams: ones that need to move fast, keep costs simple, and get real answers from logs without carrying the weight of a platform they don’t fully need yet. Here’s when that’s you.

The ability to log into all corporate applications with one username and password is pretty convenient, even compared to a password manager. As a benefit, the IT department can centrally enforce one desired two-factor auth mechanism. Now we, Icinga, also provide a so-called OpenID Connect integration for single sign-on. By the end of this text you’ll know how to connect your Icinga Web instance to the ID provider of your choice.

This blog post is part of PagerDuty’s ongoing series on how we’re helping customers navigate their journey towards autonomous operations. Read on to learn about how PD Automation Runner, now in Early Access, builds towards this vision. Your on-call engineer gets paged for a critical alert on a self-hosted Kubernetes cluster. If this were a cloud-hosted service, Workflow Actions and the SRE Agent would already be working the problem: pulling logs, checking health, surfacing a fix.

This blog post is part of PagerDuty’s ongoing series on how we’re helping customers navigate their journey towards autonomous operations. Read on to learn about how Scoped OAuth for Public Apps, now in Early Access, builds towards this vision. Your security team asks a simple question during a routine review: which third-party apps can reach our PagerDuty data right now, and what exactly can they do with it?

Table of Contents For most of Kubernetes’ history, memory management has been a blunt instrument. Cross your limit, and the kernel kills your container. There has been no equivalent to CPU throttling, no graceful backpressure, just a hard stop. With Kubernetes 1.37, that changes: Memory QoS, built on cgroups v2, graduates to Beta and is enabled by default.