DEV Community

Supraja Tangella
Supraja Tangella

Posted on

๐—ฆ๐—บ๐—ฎ๐—ฟ๐˜ ๐—”๐—น๐—ฒ๐—ฟ๐˜๐˜€: ๐—˜๐—บ๐—ฎ๐—ถ๐—น ๐—ก๐—ผ๐˜๐—ถ๐—ณ๐—ถ๐—ฐ๐—ฎ๐˜๐—ถ๐—ผ๐—ป๐˜€ ๐—ณ๐—ผ๐—ฟ ๐—”๐˜‡๐˜‚๐—ฟ๐—ฒ ๐——๐—ฒ๐˜ƒ๐—ข๐—ฝ๐˜€ ๐—–๐—œ/๐—–๐—— ๐—™๐—ฎ๐—ถ๐—น๐˜‚๐—ฟ๐—ฒ๐˜€

The 2 AM deployment failure that made me rethink our entire notification strategy

Most teams rely on the built-in notifications, which often spam everyone with irrelevant updates or miss critical deployment failures entirely.

Last month, our production deployment failed at 2 AM. The team discovered this 6 hours later, when users began to complain.

We ditched the native notifications and built a custom solution using Logic Apps + PowerShell in our YAML pipelines.

Now we get targeted emails with actual context: build numbers, timestamps, and deployment statusโ€”sent only to those who need them.


Ever miss a critical pipeline failure because of notification overload?

DevOps #AzureDevOps #CICD #DevLife #TechTips #SoftwareEngineering

Top comments (0)