Why Your 12-Hour Zabbix Alert Summary Misses Active Problems
There's something satisfying about a clean summary email. Every 12 hours, a neat report lands in your inbox, tagged, filtered, and showing exactly what your team needs to see. It feels controlled and predictable, like you've finally tamed the noise, until you realize it's only telling you half the story.
Historical alerts are easy because they're done. They're closed and 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, and the data comes back clean, with clear boundaries and no ambiguity.
Active alerts are where things get messy. The moment you try to include current problems, you're querying state instead of history, and Zabbix handles those differently. Historical events live in one world, and 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, and they won't show up in a simple "last 12 hours" query. That's the trap.
What you want is alerts that are still in problem state, which is different from alerts that happened recently. That takes 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:
- Historical events in the last 12 hours.
- Current problems regardless of start time.
Then you merge the output intelligently. A dumb append won't do; the merge should avoid duplication when 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, because that endpoint understands ongoing problem state more cleanly.
If you're on 6.x or 7.x, problem.get is your friend. It eliminates the guesswork of manually checking whether a recovery event exists and just tells you what's currently broken.
It's a little uncomfortable to admit, but 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?" Active alerts are the operational truth, and they answer the only question that really matters at 9 AM, which is what's still on fire.
The fact that you're already using tags to filter content is a strong foundation, since tags make this scalable. You can apply the same tag filters to both your historical and active queries, so 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. A better approach:
- Section 1: Active problems (open right now)
- Section 2: Problems in the last 12 hours (including resolved)
That separation prevents mental overload, because readers instantly see what needs attention and what was already handled.
There's also a subtle logic question you need to decide: do you want to include long-standing active problems in every email? If something has been open for 30 days, it'll show up every 12 hours forever. Some teams prefer that because it keeps pressure visible. Others suppress problems older than a certain threshold unless their severity changes. That's a policy decision more than 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. It keeps things open and flexible, but it also means everyone reinvents similar reporting scripts over and over, so alert summaries, SLA exports, and executive dashboards 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 is 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. If your script has more advanced formatting, aggregation, or custom logic, though, sticking with the API approach makes sense.
The core issue is almost certainly that you're querying events by time when you should be querying problems by state. Switch that mental model, and the missing active alerts problem disappears.
Once you add that second query, your summary becomes a real operational snapshot instead of a historical recap, showing what's still happening along with what happened. That's the email people actually read.