Originally published at aideazz.xyz — cross-posted here with canonical link.
My apply-queue process is critical for lead processing, and its health directly impacts my ability to convert deals. I rely on it to send timely notifications. Recently, I observed that while apply-queue.log shows ✓ sent to Telegram repeatedly, the underlying system still needs constant vigilance. This log entry confirms the attempt to send, but it doesn't guarantee the message was received or acted upon. This is a common blind spot in automated systems: the success of an internal operation doesn't always translate to the desired external outcome.
Monitoring apply-queue Health
The apply-queue process is one of eight processes supervised by PM2. It's designed to push updates to Telegram, ensuring I get immediate alerts on new leads or critical events. The logs confirm its activity: ✓ sent to Telegram is the latest outcome in apply-queue.log, modified 6.2 hours ago. This indicates the process is actively trying to send messages.
However, relying solely on log entries like "sent to Telegram" can be misleading. It confirms the internal action but not the external delivery or impact. For instance, if the Telegram API rate-limits me, or if my internet connection drops, the log might still show "sent" even if the message never reaches my device. This is why I pair these internal logs with external checks and other system health indicators.
The Broader System Context
My production environment runs several critical AI agents. Looking at pm2 jlist, I see:
-
dragontrade-dashboard: online, 1 restarts, up 40d, 56 MB -
cto-aipa: online, 167 restarts, up 2d, 249 MB -
algom-stream: online, 55193 restarts, up 40d, 53 MB -
dragontrade-main: online, 3 restarts, up 40d, 151 MB -
algom-poll: online, 0 restarts, up 59d, 72 MB -
serpapi-jobs: online, 25 restarts, up 5d, 37 MB -
whitespace: online, 4 restarts, up 39d, 102 MB -
n8n: online, 0 restarts, up 43d, 497 MB
The algom-stream process, with 55193 restarts over 40 days, stands out. This level of instability is a constant concern, even if other processes like algom-poll and n8n show 0 restarts over 59 and 43 days respectively. While apply-queue itself shows no restart count in this specific pm2 jlist output, the overall system stability affects all components. A highly unstable component can consume resources or introduce latency that impacts seemingly stable processes.
The Role of concierge-selftest
To validate the end-to-end delivery of critical alerts, I use concierge-selftest. Its latest outcome is ✅ PASS — 4 checks, 3850ms to first card, modified 6.7 hours ago. This test specifically checks if a Telegram card was produced. It also includes logic to suppress duplicates: ok duplicate suppressed (redundant drafters collapse). This is crucial for preventing alert fatigue and ensuring that only unique, actionable information reaches me.
The concierge-selftest output confirms that the mechanism for sending Telegram cards is functional. This provides a higher level of assurance than apply-queue.log alone, as it verifies the actual creation of a card, not just the internal "send" command.
Impact on Deal Flow
My HubSpot deals dashboard shows 134 deals currently at the "They replied" stage. However, I have 0 deals closed won. This gap highlights the importance of timely and reliable alerts from apply-queue. If I miss a critical reply or a new lead due to a failure in the alert system, it directly impacts my ability to move deals forward.
The reply-radar.log shows APPLY — scanned 240 · automated/own skipped 1 · no CRM match 0 · REPLIES MATCHED 0 · errors 0 and APPLY — scanned 241 · automated/own skipped 1 · no CRM match 0 · REPLIES MATCHED 0 · errors 0. This indicates that reply-radar is actively scanning and processing replies, but it's not matching any new replies that require action. This could be a normal state if there are no new replies, or it could indicate an issue if replies are indeed coming in but not being matched. The apply-queue Telegram alerts are designed to bridge this gap, notifying me when manual intervention is needed.
The Challenge of Fragmented AI Agents
My AI agents operate in a fragmented environment. As stated in NOW.md, "Cursor Cloud, Cursor Desktop and Claude Code all work this repo and none of them can see each other's chats." This means there's no shared conversation or direct inter-agent communication. NOW.md itself serves as the "working memory of whichever agent is not currently running."
This fragmentation makes robust monitoring and alerting even more critical. Each agent, including apply-queue, must be self-sufficient in its reporting, or rely on a centralized system like Telegram for critical updates. The apply-queue Telegram alerts are a direct response to this constraint, providing a unified channel for me to receive actionable information from disparate agents.
Frequently Asked Questions
Q: How do you ensure Telegram alerts are actually received, beyond the ✓ sent to Telegram log?
A: I use concierge-selftest, which verifies the end-to-end production of a Telegram card. Its output ✅ PASS — 4 checks, 3850ms to first card confirms the card was created, providing a higher level of assurance than just the internal log.
Q: What is the typical latency for a Telegram alert from apply-queue?
A: The concierge-selftest reports 3850ms to first card, which is the measured time from test initiation to the first card being produced. This gives an indication of the system's responsiveness for critical alerts.
Q: How do you handle duplicate alerts from apply-queue or other agents?
A: My concierge-selftest explicitly includes logic for duplicate suppression, logging ok duplicate suppressed (redundant drafters collapse). This prevents alert fatigue by ensuring only unique, actionable notifications are sent.
Q: What is the impact of high restart counts in other processes on apply-queue?
A: While apply-queue itself isn't listed with restarts in the pm2 jlist output, processes like algom-stream with 55193 restarts can consume system resources and potentially introduce latency or instability that indirectly affects all running processes, including apply-queue.
Top comments (0)