Originally published at aideazz.xyz — cross-posted here with canonical link.
My algom-stream process has restarted 55193 times in 32 days. This isn't a minor glitch; it's a persistent, high-frequency failure that demands a deep dive into AI agent restart analysis. In contrast, algom-poll has zero restarts over 51 days, and n8n also shows zero restarts over 35 days. This stark difference across my production agents, all supervised by PM2, highlights the critical need to understand what constitutes "online" in an AI agent context and how to interpret varying restart patterns.
The 55193-Restart Anomaly: algom-stream
The algom-stream agent, despite its 55193 restarts, is reported as "online" by PM2 and has been running for 32 days. It consumes 53 MB of memory. This indicates a process that is continuously crashing and being automatically resurrected. While PM2 ensures the service remains available, each restart represents a disruption: state loss, potential data reprocessing, and increased load on the system.
My atlas-ga4-sync.log shows "GA4 sync: 0 atlas_ rows for 2026-09-14", "GA4 sync: 0 atlas_ rows for 2026-09-15", and "GA4 sync: 0 atlas_ rows for 2026-09-16". This log, modified 13.2 hours ago, suggests that despite algom-stream being "online" for 32 days, it might not be performing its intended function of syncing data. The high restart count could be masking a deeper issue where the agent fails to complete its tasks before crashing, leading to zero output rows.
Moderate Restarts: cto-aipa and serpapi-jobs
Similarly, serpapi-jobs shows 22 restarts in less than one day, using 33 MB. This agent is relatively new or has just been restarted, making its restart count harder to contextualize over a longer period. However, 22 restarts in a single day is a warning sign. These agents, while not in the extreme failure loop of algom-stream, still require attention to identify the root causes of their instability. The VibeJobHunterAIPA_AIMCF repository, which likely relates to cto-aipa, has seen 3 commits in the last 48 hours, including "fix(judge): N+ years of overall experience is met; ingest says Bright Data, not SerpAPI" and "fix(judge): size only for certain household-name enterprises; every lane is AI work". These recent code changes suggest active development and bug fixing, which could be contributing to or addressing the observed restarts.
Stable Operations: algom-poll and n8n
In stark contrast, algom-poll has 0 restarts over 51 days, running at 72 MB. This agent demonstrates true stability. It performs its function without interruption, maintaining its state and consuming resources efficiently. The n8n process also shows 0 restarts over 35 days, using 500 MB. These agents represent the ideal state for production systems: long uptime, no unexpected restarts, and consistent performance.
The cita-sort.log, modified 0.7 hours ago, shows "cita-sort OK — 0 card(s) repositioned across 3 board(s)" for three consecutive hourly runs. This indicates a stable, predictable operation, likely managed by a reliable agent like algom-poll or n8n, where the "OK" status is consistent, even if no actions are taken.
Low Restarts: dragontrade-dashboard, dragontrade-main, whitespace
Other agents fall into a low-restart category. dragontrade-dashboard has 1 restart in 32 days (56 MB), dragontrade-main has 3 restarts in 32 days (150 MB), and whitespace has 4 restarts in 31 days (102 MB). These low numbers suggest occasional, perhaps planned, restarts or minor, self-correcting issues. They are not indicative of systemic instability but warrant monitoring. A single restart over a month could be a deployment, a configuration change, or a transient network issue. These are acceptable operational events, not critical failures.
Implications for AI Agent Operations
The data reveals a spectrum of AI agent stability. The algom-stream case (55193 restarts) is a critical issue. While PM2 keeps it "online," the underlying problem is not resolved. This pattern suggests a fundamental flaw in the agent's logic, its dependencies, or its environment, causing it to crash repeatedly. My wiki-ship.log shows "error: failed to push some refs to 'https://github.com/ElenaRevicheva/aideazz.git'" repeated three times, modified 22.0 hours ago. This kind of persistent error, even in a different system, highlights how a seemingly "online" process can still be failing to perform its core function.
For cto-aipa (151 restarts) and serpapi-jobs (22 restarts in 0 days), the focus should be on identifying the specific error conditions leading to crashes. These are likely more tractable issues than algom-stream's continuous loop. Recent commits in VibeJobHunterAIPA_AIMCF (3 in 48 hours) indicate active development, which could be a source of, or a solution to, these restarts.
The stable agents like algom-poll (0 restarts) and n8n (0 restarts) provide a baseline for healthy operation. Their long uptimes demonstrate robust design and execution. The github-token-watch.log showing "OK: 292 days left" for a token, modified 10.5 hours ago, is another example of a stable, predictable system check.
My NOW.md file describes the current operator queue: "Cursor Cloud, Cursor Desktop and Claude Code all work this repo and none of them can see each other's chats." This highlights a critical operational constraint: fragmented agent communication. When agents cannot share context, diagnosing issues like high restart counts becomes more complex. Each agent operates in its own silo, making it harder to correlate failures or understand cascading effects.
Frequently Asked Questions
Q: How do you differentiate between a "healthy" restart and a "failure" restart?
A: A healthy restart is typically planned (e.g., for deployment) or a rare, transient event. A failure restart is indicated by a high frequency of restarts over a short period, especially if accompanied by a lack of expected output, like algom-stream's 55193 restarts with zero GA4 rows.
Q: What is the first step you take when an agent shows 151 restarts in 5 days?
A: I check the agent's specific logs for error messages. For cto-aipa, I would look for patterns in the logs that correspond to the restart times, focusing on recent code changes in VibeJobHunterAIPA_AIMCF that might have introduced regressions or fixed bugs.
Q: Does PM2's "online" status mean the agent is functioning correctly?
A: No. PM2's "online" status only means the process is running and hasn't explicitly exited with an error code that PM2 doesn't handle. As shown by algom-stream's 55193 restarts and zero GA4 sync rows, an "online" agent can still be failing to perform its intended function.
Q: How do you monitor for these restart patterns?
A: I use pm2 jlist to get raw restart counts and uptime, combined with tailing specific application logs (e.g., atlas-ga4-sync.log, wiki-ship.log) to correlate restarts with functional failures or error messages.
Top comments (1)
The strongest signal here is not the restart count by itself, but the mismatch between supervisor liveness and functional completion.
PM2 = online proves that a process currently exists. It does not prove that the intended job completed, that state survived correctly, or that the produced output is valid.
For a case like algom-stream, I’d treat health as a separate state derived from evidence such as:
process alive + bounded restart rate + expected output + task completion + state continuity
Otherwise an automatic restart policy can turn a persistent failure into something that still looks operational from the outside.
I’d also be careful with 0 restarts = healthy: a process can remain alive indefinitely while doing the wrong thing. Restart count is useful evidence, but not the final health verdict.