evolutiva
EVO-58
Hostinger image-storage monitoring (api-images)
Todo low
unassigned
Establish ongoing visibility into api-images Hostinger storage. Readable today via GET /stats (X-Api-Key): per-tenant fileCount+totalBytes and a shared-disk block (totalBytes/freeBytes/percentUsed/warning). Gaps: (1) no periodic/surfaced check - build an on-demand or scheduled storage read that reports per-tenant footprint + trips on the disk warning flag; (2) the marsapi ACCOUNT quota is NOT agent-readable (Hostinger hPanel only) - resolve via Elazar hPanel check or Hostinger API creds. Current snapshot 2026-07-17: mars tenant ~1.2GB/9368 files; shared physical volume 71.4% full (warning=true) but that is the shared box, not our account. Serves mars/pluto/venus.
Sub-tickets — 0/1 done
PLUTO-605 Todo low
Questions
No questions.
Activity
-
Scoping (coder-mars-cc 2026-07-17): /stats-readable part = per-app daily Vercel cron /api/cron/storage-stats (daily only - sub-daily fails Hobby deploy) that GETs IMAGE_API_BASE_URL/stats (X-Api-Key auth), writes info-tier appEvents {fileCount,totalBytes,percentUsed}, escalates via existing alert rail. KEY: disk.warning is SERVER-WIDE + already true (71.5% at a 50% threshold) so paging on warning:true fires day-one - alert must trigger on OUR ceiling (proposed >=85%) or tenant-growth spikes, one-shot dedup. Per-tenant: each app key sees only its tenant; pluto/venus copy the route w/ their keys; PM reads the 3 appEvents streams for fleet view. Effort ~half day Mars + near-copy pluto/venus. On-demand admin tile +2h optional. Account-quota still hPanel/Elazar-blocked. Class-S (no schema/auth/email).
-
Quota confirmed via keyed SSH (~/.ssh/sshapiimage) + hPanel 2026-07-18: plan ceiling 25 GB, used 1.32 GB = 5.3%. api.pensanta.com (api-images) is 1.3G of a 1.4G account total; all other sites <54M. Alert line = 85% of 25GB = 21.25 GB used (fires ~3.75GB free). No pressure today; monitoring is low-priority (P3) daily/weekly du. Build option offered to Elazar: venus cron SSHes in, DMs only on crossing 21.25GB. SSH details in LTM.
-
4-PM design poll converged (2026-07-18): (1) CONTINUOUS awareness = per-app admin UI tile always visible 'Esta app: X GB · Pool: Y/25GB libres' — unanimous, this is Elazar's space-left-aware. (2) account-total is THE alerting number; per-app view alone hides cross-app cannibalization. (3) plumbing: ONE venus cron holds SSH key, dus 25GB account-total daily, writes small shared surface; apps pull account-total for tile + own /stats for per-app half; SSH key single-homed, NOT distributed to 3 apps. (4) graduated bands; DM on band-crossing via existing 10min-dedup rail, appEvents at warn+ only, no info noise. Variances: page 85(3of4) vs 90(mars); +optional critical95(venus); venus wanted weekly digest, others crossing-only. PM recommendation to Elazar: info60/warn75/page85/crit95, tile-both-numbers, crossing-only DMs. Owner: bin-venus-cc (needs maintainer row). Class-S. Awaiting Elazar confirm/override before dispatch.
-
Elazar FINAL spec 2026-07-18: (1) Cadence = WEEKLY, not daily ('once a day is too much' — plenty of space; 3-4mo term, ~1.3GB accrued won't approach 5GB of the 25GB ceiling). (2) Surface = storage tile on each app's admin HOME/landing control-panel route (ambient, 'not a big deal'). (3) Alert = SINGLE trigger at 75% (18.75GB) — collapses the graduated 60/75/85/95 bands; reaching 75% means something went wrong. (4) Cron owner = bin-venus-cc: weekly SSH du of the 25GB account-total, compute %, write a small shared surface the 3 apps read for the tile, DM fleet PMs + Elazar on crossing 75%. Needs maintainer-agents.sqlite row. Now ACTIONABLE — dispatching cron to bin-venus-cc + admin-landing tile to 3 app coders.
-
status=todo
chore
4w ago by wi-cli-venus
4w ago