❯ No messages in {my email} with "robo" per Hostinger.

● No reply in your inbox yet — noted, matches Robomotion's own track record of slow/no maintainer response on filed issues (#57/#58 went 5 days with zero response, per prior session notes).

Here's what the investigation actually turned up, and my honest read:

What I found

No changelog for the version actually running. GitHub's release feed for robomotionio/robomotion-next stops at v26.5.0 (published 2026-04-30). Every robot in this repo — including the one that just failed — runs v26.9.2, confirmed live in the connect logs.
That's ~5 months of shipped changes with zero public release notes, including whatever changed in exactly the area that broke (robot auth/reconnect). There's no way to check "did they push a breaking change to token validation" because they don't publish what changed between .5 and .9.2 at all.

No usable status/incident page. status.robomotion.io renders client-side with nothing in the initial HTML — no incident history retrievable without a real browser session.

No idle/heartbeat visibility, which cuts against "quiet spin-down for non-use." I pulled the full journal across the ~26-hour
silent window before the outage. There is zero log output of any kind — no heartbeat, no keepalive, no periodic status line — the
entire time. The very first log line after 26 hours of total silence is the moment we sent the stop signal. That means the client
emits no signal distinguishing "still genuinely connected" from "connection quietly died hours ago and nobody would know." So I
can't confirm or rule out a silent idle timeout — the product gives you no telemetry to check either way. That absence is itself
the finding.

What the evidence does support: the reconnect attempt with the old, previously-working token failed twice with two different
rejection codes (not_allowed, then auth_failed) before you regenerated it in the console, and the new token connected on the first
try. A token that was fine yesterday and dead today, with no client-side change, no expiration warning, and no way to inspect why
server-side — that's consistent with either a silent idle-timeout policy nobody documents, or a backend change that invalidated
live sessions. Robomotion's opacity means there's no way to tell which from our side.

Is the tech impressive?

The Designer/AI-assistant/flow-authoring side is genuinely capable — the action-compiler approach this repo built on top of it
works, and Robomotion's throughput (a real 48.9s/application proof-of-concept) is fine. But the operational substrate is fragile in
a way that matters more for a production system: this is at minimum the 6th distinct live-reproduced defect in about 48 hours
across this account (auth login/whoami rejecting valid sessions, misleading vault-not-found errors, a deterministic Timer bug, no
self-healing after a node error, silent poll-loop death, and now a silently-dying robot token) — filed as issues #59–#64, none
acknowledged by a maintainer within the same window. A platform whose core promise is "runs your robot reliably, unattended"
shouldn't have this many ways to go silently dark with zero telemetry to diagnose it after the fact. That's the accurate
characterization: capable authoring tool, hyper-fragile runtime, near-zero observability into its own failures.

Put together with everything else: the monitoring page being empty isn't a bug you're hitting, it's very likely just unpopulated for a self-hosted "Local Run" robot — Robomotion's metrics/monitoring plumbing appears built for their managed Cloud Run robots,
and a self-hosted one like Filler 1/2 probably never reports into it at all. That's consistent with everything found today: no heartbeat in the local logs, no changelog for the version you're running, no accessible incident history, and now no monitoring data either. There's no single smoking gun proving "they pushed a breaking change" — there's something arguably worse, which is that the product gives you no instrumentation anywhere to even ask the question. You're flying blind on a self-hosted robot by design, not by misconfiguration.