reflex cloud apps logs --offset is ignored; only a fixed old window is returned (start/end works)

[nourihouman]

Environment

• reflex 0.9.6.post1, reflex-hosting-cli 0.1.72
• Windows 10, Python 3.12
• App deployed to Reflex Cloud, region sjc

What happens

reflex cloud apps logs <app-id> --offset <n> returns the same set of log
entries regardless of <n>, and every entry is timestamped roughly one
month before the request. New output produced by a running app does not
appear.

Reproduction

$ date -u +%F
2026-09-26

$ reflex cloud apps logs <app-id> --offset 600      # last 10 minutes
...100 entries, newest timestamp 2026-08-27T19:44:31...

$ reflex cloud apps logs <app-id> --offset 7200     # last 2 hours
...same window, newest timestamp 2026-08-27T19:44:31...

$ reflex cloud apps logs <app-id> --offset 86400    # last 24 hours
...same window, newest timestamp 2026-08-27T19:44:31...

--loglevel error, critical and warning all return empty over any
offset, which initially reads as "the app logged no errors" rather than
"this command is not returning current data".

Expected

--offset 600 returns entries from the last 600 seconds, and log output
written by the app moments ago is retrievable.

Why it matters

This is the documented way to diagnose a production Reflex app from the
terminal. While it returns a stale window it cannot be used to confirm a
deploy, investigate an error, or check for an OOM kill, and — worse — an
empty result at --loglevel error looks like a clean bill of health. We
spent a debugging session treating "no error logs in seven days" as
evidence before noticing every returned timestamp was a month old.

The data exists server-side — see below, the same endpoint returns it when
queried a different way — so this looks like the offset query or the
window it resolves to, not log retention.

The start/end branch of the same endpoint works

GET /api/v1/apps/{id}/logsv2 takes either offset or start+end
(unix seconds). The CLI sends offset whenever it is truthy:

params = {"offset": offset} if offset else {"start": start, "end": end}

Calling the endpoint directly with start/end returns current logs
for the same app, including lines written minutes earlier. So the data is
there and the endpoint is fine; the problem is specific to the offset
path. That also gives a workaround for anyone hitting this:

httpx.get(f"{HOSTING_SERVICE}/api/v1/apps/{app_id}/logsv2",
          params={"start": int(start_ts), "end": int(end_ts)},
          headers={"Authorization": f"Bearer {token}"})

Two notes for whoever picks this up:

• The response is [rows, cursor], not a bare list of rows. Parsing it as
  a list yields a length of 2 and reads as "almost no logs" rather than as
  a parse error, which is its own small trap.
• --loglevel error returning empty while the app is healthy is
  indistinguishable from --loglevel error returning empty because the
  query window is wrong. Since this is the command people reach for during
  an incident, a silent wrong-window is worse than an error would be.

---

Reported from a production Reflex Cloud app; happy to provide the app id privately if that helps reproduce.

[linear-code]

ENG-12850