My openITCOCKPIT Telegram Module wants to grow up. Help it become an official openITCOCKPIT v5 module.
Five years ago I was drowning in emails. Now I'm fighting with architectural decisions of the openITCOCKPIT backing company.
Sixty-plus notifications a day from my own monitoring system, most of them the digital equivalent of a service shrugging and saying "eh, CPU's a bit high again" or "dude, give me more storage!".
Important alerts buried under noise I'd trained myself to ignore.
So I did what any reasonably stubborn sysadmin developer does: instead of tuning the thresholds like a sane person, I built a Telegram bot.
That was the original blog post.
A weekend project, cloned from the official openITCOCKPIT example module, glued together with the PHP Telegram Bot API, and just good enough to stop my inbox from looking like a crime scene.
I honestly didn't expect to still be running it half a decade later.
From weekend hack to something I actually trust
I have. Every single day. And somewhere along the way, "good enough" turned into "genuinely nice to use".
What started as simple notifications grew into something with real back-and-forth (around it's initial core functionality):
- 1.0 already shipped the core idea: notifications land in a chat or channel, and you can acknowledge an issue right from the bot message via a two-way webhook setup
- 1.0.1 fixed the two-way webhook auto-disabling itself when it wasn't actually configured (a small but important reliability fix)
- 1.1.0 brought multi-contact support: a chat now only receives the notifications for the openITCOCKPIT contact it's mapped to, instead of one big firehose channel for everyone
- 1.1.1 was mostly under-the-hood work, like CakePHP compatibility and Composer 2 support, so the module didn't rot as its dependencies moved on
- 1.2.0, the most recent release, is where it really grew up: official support for the openITCOCKPIT-CE Docker setup, test-message and refresh buttons right in the config page, acknowledgements now working even in one-way setups (no webhook required), a first-name fallback so people without a public Telegram username aren't locked out, and a good round of code-quality cleanup across almost every file. None of that was glamorous work. It was the unglamorous kind, the kind that turns a script into a tool. But it's exactly why I still reach for Telegram first when something on my infrastructure misbehaves, instead of squinting at yet another email.
And that's really the bigger point I want to make here: openITCOCKPIT itself has been a joy to build on top of. A clean example module to start from, a sane plugin architecture, an active team!
It's the kind of monitoring core that makes a "let's fix my notification problem" weekend spiral into a multi-year side project you're still proud of. That doesn't happen with every open-source project.
Then v5 happened
openITCOCKPIT v5 brought a modern Angular frontend, and with it, a much stricter, much more opinionated architecture. Great news for the product. Slightly less great news for a community module that, until now, happily shipped its own frontend pages alongside the core.
The backend side of my module is already prepared for v5. That part translates fine, since it's still plain CakePHP talking to the core over the same kind of interfaces it always did. The frontend is where things get genuinely hard, bordering on architecturally impossible for an outside contributor to bolt on cleanly.
Here's the actual problem: in openITCOCKPIT v4, a module's frontend was just server-rendered CakePHP views. Drop a plugin into the modules directory, and the core's plugin bootstrapping would pick up its routes and templates at runtime. No build step, no recompilation, no coordination with anything else on the system. That's precisely what made it so easy to write a module like mine as a weekend project in the first place.
v5 replaced that with a proper Angular single-page application talking to a JSON API. Which is a genuinely good move for the product: faster, more consistent UI, a real separation between frontend and backend. But an Angular app isn't a loose pile of templates the core discovers at runtime; it's a single compiled bundle, built once via the Angular CLI/webpack toolchain and shipped as a fixed artifact with each openITCOCKPIT release.
There's no equivalent of the old plugin-view discovery mechanism for injecting a new component, a new route, or a new settings page into an already-compiled bundle from the outside. Technically there are some possibilities, but not provided by openITCOCKPIT and not that easy to built-in within a hour.
To add a module's UI, you'd effectively need to rebuild and re-ship the entire frontend application together with it - which isn't something a loosely coupled, independently versioned community module can reasonably do on its own. And if you'd have only a second, distinct community module with its own frontend, you can't ever bring them together without fancy tech (not available here) or you'll need to compile it yourself in your productive setup.
So with the current module system, there's no good way to ship a community-maintained Angular frontend alongside a community-maintained backend.
I see roughly four ways forward:
- Give up and switch to a different monitoring tool or notification method (please, no)
- Build a standalone frontend app that talks to the openITCOCKPIT API on its own
- Try to smuggle a standalone frontend app in within the application somehow (untested, possibly not even possible)
- Get the whole module adopted as an official, first-party community module in the openITCOCKPIT repository itself
Option four is, by a wide margin, the one I actually want. It sidesteps the whole community-frontend architecture problem, because it would live and ship inside the core project rather than bolt onto it from outside. It also means the module gets maintained with the same rigor, review, and longevity as everything else in openITCOCKPIT, instead of depending on one guy with a blog keeping it alive between day-job commitments.
I've already opened the door on this: there's a pull request, openITCOCKPIT/openITCOCKPIT#1957, proposing exactly that: contributing the Telegram module as an official part of openITCOCKPIT.
Where you come in
If you're one of the people quietly using this module too, or if you just like the idea of monitoring notifications that don't require you to babysit an inbox, I'd genuinely appreciate a hand:
👍 the issue so the maintainers can see there's actual demand behind this, not just me being attached to my own code
Drop a comment or reaction on PR #1957 if you'd like to see it merged
Or just try the module on your current v4 setup and tell me what breaks. The releases page and the project README is your entrypoint.
I love this project, I love that openITCOCKPIT made it possible to build in the first place, and I'd genuinely love for it to have a future beyond "the module that guy maintains on the side". With a bit of community noise, maybe v5 won't mean the end of an era ... just the start of a more official one :)