Engineering teams at Visibility Logic were not catching Jira updates in time. Email notifications piled up and got ignored. The team was already communicating on Telegram, but there was no bridge between where the work was tracked and where people were actually present.
Overview
PM Notifier is an automation tool that bridges Jira and Telegram for engineering and product teams. It runs on GitHub Actions every 3 minutes, polls Jira for any activity since the last run, and pushes targeted notifications directly to team members' Telegram accounts.
The system is stateful: it tracks what it has already notified about to prevent duplicates across runs. State is committed back to the repository as a JSON file after each run, which means it persists without needing a separate database or server.
My Role
Identified the team communication gap: Jira notifications were not reaching people where they were actually working
Designed the notification taxonomy: which Jira events are worth an interruption, what each message should contain, and who receives it
Defined the state management approach: a JSON file committed to the repo after each run, making the system idempotent without needing a separate database
Chose GitHub Actions as the runtime to eliminate infrastructure overhead entirely
Defined the weekly summary format for Monday PM review: open tasks by assignee, completed since last week, and blocked items
Built and deployed the full system as the PM who needed it and the engineer who shipped it.
Python script running inside a GitHub Actions workflow on a 3-minute cron schedule. The script imports Telethon for Telegram access and makes direct HTTP requests to the Jira REST API. No server, no database, no infrastructure beyond the GitHub repository itself.
State is stored in a JSON file in the repo. After each run, any new notifications are recorded in state and the file is committed back. User mapping (Jira account ID to Telegram user) is configured in the repo. Secrets are stored in GitHub Actions secrets and injected into the workflow environment.
Key Decisions
GitHub Actions as the runtime, not a server
GitHub Actions gives a free hosted runner that executes on schedule with zero infrastructure management. The 3-minute minimum cron interval was the deciding factor: frequent enough to feel real-time without needing a persistent process.
State in the repository rather than a database
A database would require a separate service and credentials. Storing state as a committed JSON file keeps everything in one place: code, config, and state all live in the same repository.
Telethon instead of the Telegram Bot API
The Telegram Bot API requires users to start a conversation with the bot before it can message them. Telethon operates as a full Telegram account, which means it can message any user directly without that precondition.
Targeted per-user notifications rather than a group broadcast
A group channel approach would mean everyone sees every notification, even for tasks assigned to someone else. Sending each notification to the relevant individual keeps the signal-to-noise ratio high.
Challenges
Preventing duplicate notifications across 3-minute runs
Jira does not provide a clean webhook-style event stream. The state file tracks every notification by a combination of issue key and event type so that the same event is never dispatched twice.
Mapping Jira users to Telegram accounts reliably
The Jira API returns account IDs for assignees and commenters. Telegram uses usernames or numeric user IDs. The mapping has to be maintained manually when someone joins the team.
Discovery
The problem was straightforward. Jira notifications were going to email, and nobody was reading them. The team was communicating on Telegram and nowhere else. Assignment updates were being missed, status changes were going unnoticed, and the weekly catch-up was the only moment anyone had a shared view of what was actually happening.
Stakeholder Friction
The one design debate was polling versus webhooks. Webhooks would have been more efficient but required a persistent endpoint to receive Jira's payloads, which meant provisioning and maintaining a server. Polling on GitHub Actions kept everything serverless with zero ongoing cost or maintenance.
Outcomes
1,000+ notifications delivered to 15 team members
1,000+ targeted notifications delivered across a 15-person engineering team since deployment, with zero duplicate dispatches. Still running in production at Visibility Logic.
Weekly summary replaced manual Jira check-ins
Monday PM review now uses the automated weekly summary as its baseline rather than manually querying Jira before the meeting. Saves approximately 20 minutes of prep per weekly review.
A configuration UI for managing the team mapping. Adding or removing a team member currently requires editing a JSON file, committing it, and pushing to the repository. A simple admin page for managing the Jira-to-Telegram user mapping would extend the tool's useful lifespan and make onboarding new team members something any PM could handle without touching code.