Observability Without Dashboards via Notifications | Daniel Tinizaray

Why This Matters Right Now

Every processing pipeline —video, ETL, CI/CD, inference— emits events. Usually we ignore them or forward them to an external monitoring system with all the paraphernalia: dashboards, alerts, retention policies, dedicated teams.

But there's a simpler pattern: listen to the notifications your system already publishes.

I'm not talking about replacing Datadog at a 500-person company. I'm talking about the 90% of small-to-medium teams who spend more time configuring dashboards than they save using them. Teams that have a working pipeline, code that publishes events to some channel (a webhook, a queue, a simple pub/sub), and all the information they need is already there —they just need to read it.

1. Your Pipeline Already Talks. Are You Listening?

Every time your system completes a job, it publishes a message. It usually includes:

• Status (success/error)
• Total duration
• Process-specific metrics (file size, processing speed, bottleneck detected)
• Start and end timestamps
• User or project that triggered it

That raw message is already more valuable than most dashboards you'd build later. The problem isn't a lack of data —it's that this data gets lost in a sea of unread notifications.

The solution isn't another dashboard. It's a parser that reads those messages, structures them, and compares them against historical baselines.

2. The Pattern: Event Queue → Parser → Report

The cycle is simple and applies to any pipeline:

1. Source: Your pipeline publishes structured events (flat JSON) to a lightweight pub/sub channel —NTFY, a Slack webhook, SQS, Redis, or even a rotated log file.
2. Parser: A process (a serverless hook, a cron script, or an agent) consumes those messages, extracts relevant metrics, and normalizes them.
3. Comparator: It compares current data against a historical baseline stored locally.
4. Report: If there are meaningful changes, it generates a report. If not, silence.

The trick is not processing everything. The parser only needs to answer one question: "Did this change from what I saw before?" If it didn't, you don't report. If it did, you say what and how much.

3. What You Gain

• Zero monitoring infrastructure. No retention, no indices, no query languages. Your data is flat JSON files.
• Reports in natural language, not charts. An analytical agent reads the data and summarizes: "throughput went up 30%," "yesterday's jobs were 2s slower on detection."
• Real historical context. Not 15-minute metrics. You compare against days and weeks with second-long queries.
• No noise. You only report when something meaningful changed.

All of this works with the pub/sub event source you already have. No agents, no exporters, no external systems.

4. A Concrete (Abstract) Example

Imagine a pipeline processing media files. Each completed job looks like this:

📁 Project: Alpha
📐 clip_duration_sec: 108.11
📊 render: 3m 37s, detection: 1m 43s
🕒 Start: 10:15:00, End: 10:21:24

A hook captures that, stores it in a 300-line JSON file, and at the end of the day an agent responds:

"You processed 7 files today (4.9 min of content). Throughput went from 0.38x to 0.51x. NVECC stayed at 1."
"3 of 7 jobs had parallel processing. Render remains the bottleneck."

Without opening a single dashboard.

5. When NOT to Use This

This pattern has clear limits:

• Doesn't replace real-time monitoring for critical systems (payments, health, security).
• Not suitable when you need sub-second alerts with guaranteed latency.
• Doesn't scale to thousands of events per minute without additional structure.

But for 90% of processing pipelines —the ones that run in batches, take minutes, and generate dozens or hundreds of events per day— it's more than enough.

Conclusion

Our obsession with dashboards made us forget that the most valuable data is already in the events our systems publish. Parsing them directly, comparing against history, and getting natural language reports doesn't require expensive tools. It just requires listening.