Your 12-Hour Alert Summary Is Nice, But It's Missing the Most Important Problems

**Your 12-Hour Alert Summary Is Nice—But Here’s Why It’s Missing the Most Important Problems** There’s something satisfying about a clean summary email. Every 12 hours, a neat report lands in your inbox. Tagged. Filtered. Exactly what your team needs to see. It feels controlled. Predictable. Like you’ve finally tamed the noise. Until you realize it’s only telling you half the story . Because historical alerts are easy. They’re done. Closed. Wrapped up in a tidy time window. You query events from the last 12 hours, apply your tag filters, format the output, and send it off. Clean data. Clear boundaries. No ambiguity. Active alerts? That’s where things get messy. The moment you try to include current problems, you’re no longer querying history. You’re querying state. And Zabbix handles those differently. Historical events live in one world. Ongoing problems live in another. If your script is pulling from `event.get` with a time filter, you’re probably capturing only events that occurred in the past 12 hours. That works perfectly for summary reporting. But active alerts might have started 3 days ago and still be open. They won’t show up in a simple “last 12 hours” query. And that’s the trap. You don’t want “alerts that happened recently.” You want “alerts that are still in problem state.” That’s a different API call—or at least a different filter. Instead of filtering by time, you need to filter by `value=1` (problem state) and `recent=true` or equivalent logic depending on your API approach. In other words, your summary script likely needs two queries: 1. Historical events in the last 12 hours. 2. Current problems regardless of start time. Then you merge the output intelligently. Not just a dumb append, but something that avoids duplication if a problem both started in the last 12 hours and is still active. This is where people often get stuck. They’ve built a reporting script around event history, but active problems are better pulled from `problem.get` in newer Zabbix versions. That endpoint understands ongoing problem state in a cleaner way. If you’re on 6.x or 7.x, `problem.get` is your friend. It eliminates the guesswork of manually checking if a recovery event exists. It just tells you what’s currently broken. And here’s the uncomfortable truth: your active alerts section might be more valuable than your historical summary. Historical summaries are great for trend awareness. “What broke overnight?” “What flapped this morning?” But active alerts are operational truth. They answer the only question that really matters at 9 AM: What’s still on fire? The fact that you’re already using tags to filter content is a strong foundation. Tags make this scalable. You can apply the same tag filters to both your historical and active queries, ensuring your email only includes what your team actually cares about. The structure of the email matters too. If you just dump active alerts into the same section as historical ones, it becomes confusing. Better approach: - Section 1: Active Problems (open right now) - Section 2: Problems in Last 12 Hours (including resolved) That separation prevents mental overload. Readers instantly see what needs attention versus what was handled. There’s also a subtle logic issue you need to decide on: do you want to include long-standing active problems in every email? Because if something has been open for 30 days, it’ll show up every 12 hours forever. Some teams prefer that. It keeps pressure visible. Others suppress problems older than a certain threshold unless their severity changes. That’s a policy decision, not a technical one. The other question raised—whether there’s a shared script repository for this kind of thing —is interesting. There isn’t really a centralized Zabbix “script marketplace.” Most people just throw their ad hoc tools on GitHub and share them if others might benefit. That’s both a blessing and a curse. On one hand, it keeps things open and flexible. On the other, it means everyone reinvents similar reporting scripts over and over. Alert summaries. SLA exports. Executive dashboards. They exist in dozens of private repos. If you polish yours and publish it, odds are someone else is fighting the exact same battle. One more angle worth considering: do you even need a standalone script? Zabbix supports scheduled reports in newer versions. If your use case is purely email summaries, you might be able to build a custom dashboard with filtered widgets (based on tags), then schedule it as a report. That approach automatically includes active problems because dashboards reflect current state. But if your script has more advanced formatting, aggregation, or custom logic, sticking with the API approach makes sense. The core issue, though, is almost certainly this: you’re querying events by time, not querying problems by state. Switch that mental model, and the missing active alerts problem disappears. And once you add that second query, your summary stops being a historical recap and becomes something more powerful—a real operational snapshot. Not just what happened. But what’s still happening. That’s the email people actually read.