DeviiPulse

Operations teams don’t miss incidents because nobody built a dashboard — they miss them because the alert arrived on the wrong channel, at the wrong time, or buried under noise from systems they don’t own. Email threads and generic monitoring pings don’t survive a phone in a pocket during a real outage.

DeviiPulse is a focused mobile alerting product I built and shipped under Deviitor: real-time push notifications for operational events, per-channel subscription so each responder follows only what they’re responsible for, flexible snooze controls when an alert is acknowledged but not actionable yet, and a clean seven-day history timeline when you need context after the fact.

When an alert needs deeper investigation, the app opens the linked incident page in the browser — keeping the mobile experience fast and read-only while status pages carry the full postmortem. It’s built for on-call and SRE workflows where the goal is faster awareness, not another admin console in your pocket.

Goals & Success Criteria

“Done and good” meant four things: critical alerts reach the phone in real time via push, not email; each user controls which channels they follow instead of inheriting a firehose; snooze is flexible enough to pause a noisy source for hours or days without unsubscribing; and the last week of alerts is reviewable in one timeline with a path to the full incident write-up.

Approach & Key Decisions

Channel subscriptions over broadcast-all. Every alert source is a channel — CPU utilization, API error rate, replication lag — and users explicitly subscribe or unsubscribe. That keeps on-call noise down and mirrors how teams actually divide ownership. The trade-off: more UI surface than a single inbox, but far less alert fatigue.

Snooze at the source, not just globally. Alerts can be snoozed per channel with preset durations (1, 3, 7, 14 days) or a custom window — including unsnooze when the issue is resolved. I rejected a single global “do not disturb” because operations teams often need one channel quiet while another stays hot.

FCM push with a server-side alert pipeline. Both mobile clients register for Firebase Cloud Messaging; a Node.js API receives job events from monitoring probes, resolves subscribers for that channel, and delivers notifications with enough payload for the timeline and detail sheet. The trade-off: operating push infrastructure, but native delivery on iOS and Android that survives backgrounding.

Flutter for iOS and Android from one codebase. One client ships to both stores so channel subscriptions, snooze, and history stay in lockstep — a push-payload or UI fix lands once. The trade-off: platform-specific notification permission and background-delivery quirks still have to be tested on real devices, not assumed from the shared Dart layer.

Browser handoff for incident depth. Tapping through opens status.deviipulse.com (or the linked URL on the alert) rather than rebuilding a full incident-management UI inside the app. Mobile stays fast; the status page carries charts, timelines, and runbooks.

Challenges

Duplicate delivery was the first production bug worth fixing: the same event could surface twice in notifications when the probe and delivery pipeline both fired for one job. Tracing the FCM path end to end — job ingest, subscriber resolution, token dispatch — and deduplicating at the right layer was necessary before the app felt trustworthy on a real on-call rotation.

Snooze semantics had to be obvious in the UI. “Snoozed until 2026-04-18 20:00” on a channel card, with subscribe/unsnooze actions visible in the same row, so responders know at a glance whether they will hear from that source again tonight.

Results & Impact

DeviiPulse is live on the App Store and Google Play (v1.0.14) under Deviitor (PVT) LTD — free for iPhone and Android, built for operations and on-call workflows. Users get real-time push alerts, channel-level control, snooze, seven-day history, and one-tap access to incident details. It is the mobile layer I wanted for teams who already have monitoring but need alerts that actually reach the person on call.

What I’d Do Differently

I would run TestFlight and a Play internal track in parallel from the first push build. Shipping both stores is the right product shape; validating FCM on Android earlier would have caught device-specific background-delivery quirks before the public listings went live.