n8n Automation Hub
The same Telegram error, a different mistake
This n8n instance already has one article about a Telegram sendMessage node failing with can't parse entities — that one came from a Markdown parse mode choking on a stray character an LLM had generated in a caption. This is the same error class, on an unrelated workflow, from a genuinely different mistake: a message template that still had an HTML <b> tag in it, paired with a node that had never had its parse mode explicitly set.
The node is Telegram - Render Failed inside WF - Geld Verstehen Creator, a watchdog step that fires when a MoneyPrinterTurbo video render doesn't finish after a set number of retries. It's not customer-facing — it's an internal alert to a personal Telegram chat — which is exactly the kind of low-visibility node where a broken alert can sit unnoticed for a while, because the only symptom is that the alert itself never arrives.
What the error actually pointed at
Telegram's Bot API returned 400: can't parse entities: Can't find end of the entity starting at byte offset 83. That error means Telegram tried to interpret the message text as formatted content — HTML or Markdown entities like <b>, *bold*, _italic_ — and found a tag or marker it couldn't close. Byte offset 83 landed inside a <b> that opened a bolded warning line but had no matching close before the message ended awkwardly for Telegram's parser.
The n8n Telegram node's additionalFields.parseMode controls how the outgoing text is interpreted: HTML, Markdown, or none. When it's left unset, the node still sends a default parse mode to the Telegram API rather than sending raw text — so any angle brackets or Markdown-looking characters in the message get interpreted whether or not that was the intent. This node's text was written with an HTML tag for emphasis but without ever setting parseMode to HTML to match — a mismatch between what the text assumed and what the node was configured to do.
Fixed by removing the ambiguity, not by picking the "right" parse mode
The live node configuration, read fresh via the n8n API, shows the fix that's already in place: the <b> tag is gone from the message text entirely, and additionalFields.parseMode is now explicitly set to "none". Rather than fixing the mismatch by setting parseMode to HTML and keeping the tag, the simpler direction was taken — an internal alert message doesn't need bold text badly enough to carry the risk of a future edit reintroducing an unescaped character that breaks parsing again.
That's a meaningfully different fix than the other Telegram article on this site, where the resolution was to set parseMode: "none" on a message whose formatting was accidental (an LLM's stray character), not the point of the message. Here, the formatting was intentional at some point but got orphaned when the text was edited, and the safer call was to drop it.
The sibling node that hasn't broken yet
The same workflow has a second Telegram node, Telegram - Queue Exhausted, that fires when a content topic queue runs dry. Its text still contains an HTML <b> tag, and its parseMode is also unset — the identical latent setup that broke the render-failed alert. It hasn't errored, most likely because its fixed message text happens not to contain any character that trips up whatever default parsing n8n applies when parseMode is left blank. That's not a guarantee it stays safe; it's simply a message that hasn't yet hit the specific shape that causes a parse failure. Left as-is for now, since fixing a node that isn't actually failing wasn't part of this check — worth revisiting if it ever throws the same error.
What confirmed it
There's no way to force this exact historical error on demand without deliberately breaking the node again, so the confirmation here is a direct read of the live node configuration via the n8n API: no <b> tag in the text, parseMode: "none" present in additionalFields. The workflow is confirmed still active: true.