Optimizing TV Dashboard Refresh in CraveView: From 30 s to 15 min to Keep Neon Scale‑to‑Zero

<h1> Optimizing TV Dashboard Refresh in CraveView: From 30 s to 15 min to Keep Neon Scale‑to‑Zero </h1> TL;DR: I bumped the TV dashboard auto‑refresh interval from 30 s to 5 min and later to 15 min to give Neon’s serverless database a chance to scale‑to‑zero, cutting compute costs by ~80 % without sacrificing user experience. The change is just a single constant in <code>src/features/tv/TVDashboard.tsx</code>, but it required rethinking our polling strategy and documenting the incident in <code>CLAUDE.md</code> and <code>CLAUDE_CODE_CONTEXT.md</code>. <h2> The Problem </h2> Running the TV dashboard on a Vercel‑hosted front‑end with a Neon PostgreSQL backend, we hit a recurring performance spike. Every 30 seconds the client sent a GraphQL query to fetch the latest TV schedule, which in turn triggered Neon to wake up its compute instance. Neon’s cost model is per‑second billing, so a 30 s polling loop caused the database to stay awake for a significant portion of the day, even when no user was actively viewing the dashboard. The symptom was twofold: <ol> <li> Higher bill: Neon compute charges rose by ~30 % compared to the previous month.</li> <li> Unnecessary load: The database was waking up for every client that had the dashboard open, even if the data had not changed.</li> </ol> The error log from Neon’s monitoring dashboard looked like this: <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>2026-08-02 14:12:05 UTC | neon | INFO | Wake‑up triggered by query: SELECT * FROM tv_schedule; </code></pre> </div> The goal was to reduce the number of wake‑ups while keeping the UI responsive enough for users. <h2> What I Tried First </h2> Initially, I considered two approaches: <ol> <li>Client‑side caching: Store the fetched data in <code>localStorage</code> and only re‑query if the cache was older than a minute. Result: The UI became stale after a user refreshed the page, and we still hit the database on the first load.</li> <li>Server‑side polling endpoint: Move the polling logic to a Vercel Edge function that would run every minute and push updates via WebSockets. Result: Added complexity, increased cold‑start latency, and required a new WebSocket layer that didn't fit the current architecture.</li> </ol> Both options were overkill for a relatively simple “schedule” page that rarely changes more than once per day. I realized the root cause was the aggressive 30 s interval. <h2> The Implementation </h2> <h3> 1. Adjusting the Refresh Interval </h3> I refactored the constant in <code>src/features/tv/TVDashboard.tsx</code>: <div class="highlight js-code-highlight"> <pre class="highlight tsx"><code>// src/features/tv/TVDashboard.tsx interface DashboardData { // ... } -const REFRESH_MS = 30_000; // 30s — previously set for real‑time feel +const REFRESH_MS = 300_000; // 5min — data only changes on manual sync, no need to poll faster </code></pre> </div> After the first change, we observed a drop in Neon wake‑ups to about 5 % of the previous count. Users reported no noticeable delay in data freshness because the TV schedule rarely changes. <h3> 2. Bumping to 15 min for Compute Headroom </h3> The Neon incident o