You have tabs open. Stripe. Your analytics. The database admin panel. You check them on a loop. It’s not a workflow — it’s anxiety management.

The fix isn’t a better dashboard. It’s not checking at all.

#What dashboards are for

Dashboards are good at one thing: showing state on demand. When you need to understand what happened over the last week, a dashboard is the right tool.

They’re bad at the other thing developers use them for: learning that something happened. For that, you’re polling. You refresh. Nothing. Refresh. Nothing. Refresh. There it is.

Polling is a waste of attention. The moment something happens, your code knows. You don’t have to wait.

#The alternative: your product tells you

When a user signs up, your server processes the request. It knows immediately. The notification can fire at that moment — not when you next open a browser tab.

// In your signup handler
const user = await createUser(req.body)
fyi("New signup", { body: user.email })
return user

That’s it. The notification fires when the event fires. Not when you check.

#What’s worth notifying on

Not everything. The goal isn’t a fire hose — it’s quiet confidence that the things that matter are working.

Worth a push notification (fyi()):

• First signup from a new user
• Payment received
• A long job finished
• Something unexpected (but not a system failure)

Worth recording silently (fyi.log()):

• Cache refreshed
• Scheduled job ran normally
• API request processed
• Background sync completed

Worth urgency (fyi.critical()):

• Payment failed (third attempt)
• Job crashed with no retry
• Something that requires action now

The difference between fyi() and fyi.log() is whether you want to be interrupted. Most events don’t warrant an interrupt.

#The habit that replaces dashboard-checking

The loop is simple:

1. Something happens in your product
2. You know about it
3. If it needs action, you act
4. If it doesn’t, you go back to what you were doing

The dashboard loop breaks because you’re always the one initiating. You refresh, find nothing, and feel like you need to refresh again soon. The notification loop inverts it — the product initiates, you respond.

The internal trigger shifts: instead of “I should go check Stripe,” it becomes “Stripe will tell me.”

#Instrumentation grows over time

You don’t have to instrument everything at once. Start with the one event that you currently check manually on a loop.

If you refresh Stripe every hour to see if anyone paid: instrument payments.

If you open the database to see if anyone signed up: instrument signups.

If you tail logs to see if a cron job ran: instrument the cron job.

One event. Get the notification. Trust it. Then add the next one.

After a few weeks, you’ll stop opening the dashboard at all — not because you told yourself to, but because there’s nothing left to check.

#The second order effect

When notifications are reliable, you stop building anxiety-checking into your workflow. Your attention stays where you put it. The refresh tab stays closed.

This is the actual product. Not the technical implementation — the change in how you relate to your running code.

The dashboard shows you what happened. trigger.fyi tells you when it happens.

#Setup

npx trigger.fyi

Generates a key, subscribes your device. Start with one event. Trust the notification when it comes. Add the next event when you find yourself checking something manually again.

Related: Backend push notifications · Background job notifications · Heartbeat monitoring · Push notifications from Go