This is EventSend

When your app goes down, don't wait for the fix to post the first update. "We're on it" beats silence. During Railway's rough week, one founder's biggest complaint wasn't the outage. It was "zero response from the team".

A Stripe dispute is the one payment alert with a clock on it. Miss the response window and you lose by default, even if you were right. Send disputes where they can't scroll away, with the due date in the message. Failed payments can wait till morning. Disputes can't wait.

Check where your alerts run. If they live in the same cloud region as your app, one outage takes out the app and the warning. Google Cloud's London region went down this morning. Banks, court video links, and delivery apps went down with it.

An alert posted to a channel with 12 people is an alert nobody owns. Everyone sees it. Everyone figures someone else has it. Make it a rule: first person on it reacts 👀 and replies "mine." Now the other 11 can go back to work. How does your team claim alerts?

Building shit so other's shit is not that shitty

An AI that looks into your 3am alert still woke you up at 3am. Fix the routing first. Send only what someone has to fix tonight to a phone. Everything else can wait in a channel until morning.

It's Friday. Send one test alert to your phone before you log off. Slack apps get uninstalled, tokens get rotated, someone archives the old #alerts channel. Better to find out it's broken at 2pm today than at 3am Saturday. When did you last test yours?

No alerts doesn't always mean nothing's wrong. Yesterday Hookdeck, a company whose whole job is delivering webhooks, ran slow for almost two hours because a Google Cloud service it relies on had trouble. If events usually arrive every few minutes, alert when they stop.

A late payment webhook is not a failed payment. Mercado Pago's payment webhooks ran slow for about 20 minutes yesterday. Before you cancel an order or email "your payment failed", check the payment itself. Silence usually just means wait.

This week we launched @smollaunch, so if anyone could help us with a vote we'd really appreciate it! smollaunch.com/products/even…

After an outage, hours of old alerts can land all at once. Put the time it happened first in every alert, not the time it arrived. Then nobody spends their morning chasing a problem that got fixed at 3am.

A Slack webhook URL is a password that can post as your bot. If it ever landed in an AI prompt, a log, or a gist, rotate it now. Treat those URLs like keys, not config.

When CircleCI broke Tuesday, its webhooks and notifications ran hours late too. The tool that broke was also the tool that was supposed to tell you. Keep one alert that doesn't depend on the thing it's watching. Even a plain "no build finished in 2 hours" check counts.

No deploy ping doesn't mean the deploy worked. GitHub Actions was down for over three hours this Monday. Jobs sat stuck or failed, and a lot of team channels just went quiet. Alert when a job fails or sits stuck too long, not only when it ships. How long before you'd notice?

🏆 EventSend just earned "Top 5 This Week" on @launch_llama! #3 overall 37 upvotes

One event. One wake. If Slack, PagerDuty, and email all yell the same incident, you built a mute factory. Route once. Let the other channels stay quiet.

Payment webhooks don't keep score. "refunded" can hit Slack before "paid", same charge, wrong story for the team. Trust the event id and timestamp, not which ping showed up first. How do you keep payment alerts from rewriting history?

Webhooks will arrive twice, and out of order, plan for that. If your handler is not idempotent, every retry is a bug.

Alert fatigue is not too many channels, it's too many "urgent" pings that were never really urgent. Route status and FYI events to a silent digest. Wake on-call only when someone has to act immediately. If everything feels urgent, nothing is.