Operations | Monitoring | ITSM | DevOps | Cloud

Life is pretty good. I’ve shipped a mobile app and I’m (happily) drowning in telemetry. Battery impact, time in foreground/background per screen, crash rates, slow frames, network retries – the works. The data is brilliant; the challenge is turning signals into reliable alerts that catch real issues which are relevant to my app’s functions. So… what should I actually listen for, and where should I set the thresholds?

When your team shares one support number, someone has to decide who gets the calls when customers need help after hours. And if your team rotates on-call responsibilities weekly, which is common in IT (SRE, DevOps, ITOps, etc), clinical and field engineering teams, you’ve probably relied on manual call forwarding at some point. On paper, it seems straightforward: update the forwarding number each week to point to the person who’s on call. In practice? It often turns into a scramble.

When AT&T officially shut down its email-to-text and text-to-email service on June 17, 2025, a quiet but essential part of many organizations’ communication workflows disappeared overnight. Messages that used to be sent to addresses like simply stopped delivering. For teams who relied on those alerts to reach the on-call clinician, engineer, technician, or service lead — this created an unexpected and urgent gap. This wasn’t just a convenience feature going away.

When teams manage a high volume of alerts, it’s easy for things to start blending together. A system outage, a temperature warning, a network slowdown – without a way to quickly identify what’s what, it takes longer to triage and prioritize. Especially on mobile, scrolling through a list of similar-looking alerts can slow your response and add confusion during incidents.