TL;DR

Handler is an alert notification app for phones: supporting Alertmanager and plain webhooks in, push notifications with ack, quiet hours, and per-priority sounds. Open beta means I'm looking for people who wants to test it, give their feedback and if they wany to stay I'm going to give lifetime free access according to their needs.

Hi everyone!

I want to show you an app I have been building for the last few months.

Features

• Apple: Time Sensitive notifications. Apple Critical Alerts that bypass phone silent mode (currently wainting for entitle);
• Apple: Enhanced Notifications (more detail on long press, Ack without opening the app);
• Emergency/Critical alerts retry every minute until you Ack them;
• Separate notification channels and sounds per priority;
• Weekly quiet-hours schedule (notifications still arrive; sound stays off unless bypass rules say otherwise);
• Notification list with swipe to Ack, filters, and search;
• Active alerts list (no resolve yet), filters, search;
• Alert detail with history of actions and identical alerts merging;
• Global mute (snooze);
• Per-priority sounds and volumes that can override the system default;
• Channels to separate environments. Two built-in types today:
  • Universal: webhook with severity, labels, and related fields;
  • Alertmanager: groups, severity, labels, fingerprint, resolve;
  • More to come, if you need anything say so on Discord.

A few words about me

Day to day, for 8 years I have been the only DevOps in a small company, running 10+ dedicated servers, dozens of VMs, and a few hundred Kubernetes pods for client software.

For 4 years I have also been building a garage homelab. I love self-hosted culture.

I built Handler from mistakes, experience, and my own needs. Existing tools did not match what I wanted on a lock screen when something was on fire.

Architecture

The problem is not exotic, so the design stays simple.

• Application logic is separate from notification sending. Workers use two queues (inbound and outbound) so accept and deliver do not share one bottleneck.
• The stack is not locked to one cloud. Docker, Kubernetes, or on-prem are all in scope. For hosted beta I run a scalable AWS setup because I treat delivery as critical infrastructure: alerts are useless if they never reach engineers. A Community Edition for everyone is on the roadmap.
• Backend is Go and stays light. On my machines, notification logic processing on that path is under about 40ms.
• I started mobile with React Native, then rewrote to native Kotlin and Swift for reliability. That delayed the public release a bit.

Security

• This app was built with good security practices in mind (full encryption in transit and at rest). The pipeline includes advanced tests and vulnerability monitors. For several months I tested the app myself and ran pen-tests.
• This is not end-to-end encryption at the moment (that’s on the roadmap as alternative mode), because the app implements features (e.g. merging identical alerts into a shared history) so the processing is needed.

Mission

I wanted something that can cut through the noise of chat apps. Slack and Discord webhooks are fine for chat; they are a weak pager. I had that problem myself. Market options felt unsupported, buggy, or outdated, so I built Handler.

There is a Free tier on purpose. I want this usable for people who need it, including homelab. Over time I want a Community Edition people can run themselves, and a community that argues about how it should work.

Why not self-hosted? (for now)

That was the original plan.

Real push with the app closed needs FCM and APNs. Both expect private credentials in a backend that can send. I will not casually share those secrets with every random instance.

I do not have a clean answer yet. That bothers me, because I live in the self-hosted world every day.

Compromise for now: hosted Free tier, and a roadmap toward a Community Edition (open source, self-host ready). Longer term I am thinking about releasing mobile sources so someone can ship their own app pointed at their own backend (that still means Apple and Google developer accounts).

Discord is open if you want to discuss about a secure open design.

Early adopters

A few dozen people who create an account, join Discord, and actively test for about a month, then want to stay: free lifetime access to a plan that fits what you need is granted. Details and signup live in the Discord pin.

My daily driver is Apple, so iOS is usually ahead. Android feedback is especially welcome.

Roadmap

• Stronger integration and E2E tests before more features
• Polishing and customization
• Team features (shared channels across people and devices)
• Community Edition for self-host
• Other operating modes (including an E2E encryption mode that does not store or process encoded notification content)

Where was artificial intelligence used in this project?

I think that should be public.

I used agents for research, specs, and documentation updates; some help on UI (not my strongest area); and "prove me wrong" style conversations.

Architecture, lo-fi mockups, backend, mobile apps, and Terraform are mine, from my know-how.

A request to leave something behind

I’d love any feedback. I have never published anything like this before. Tell me what you think, and especially what to improve.

If this would be useful but you are not using it, say what is wrong or what is missing.

I'm Kerolos, founder of OutageDeck.

The question I wanted to answer quickly was: is my app broken, or is AWS, Cloudflare, GitHub, OpenAI, Stripe, or another dependency reporting an incident?

I built OutageDeck to read and normalize the official status sources for 172 cloud and SaaS providers. It shows provider and service-level state, current incidents, source freshness, incident history, and 90-day uptime in one place.

What works today:

- check a whole dependency stack without creating an account

- free email alerts for up to five providers

- Slack, Teams, Discord, and webhook destinations on paid plans

- a keyless JSON API, RSS feeds, badges, CLI tools, and an MCP endpoint

- custom Statuspage or Instatus feeds on paid plans

What it deliberately does not do is pretend an official status feed is independent truth. Providers can acknowledge incidents late, so I think a serious production setup should use two signals: the vendor feed plus synthetic probes from your own regions and accounts.

You can try the stack checker here:

https://outagedeck.com/stack?utm_source=reddit&utm_medium=community&utm_campaign=sideproject_provider_monitoring

I would value blunt feedback from people who handle incidents. What would this need to do before you would keep it open or route its alerts into your on-call workflow?