Confirmed releaseThe detail chart scales to the sandbox memory limit and draws a dashed reference line at 85 percent of that limit.
Vercel Sandbox now reports memory use across dashboard and CLI
Vercel's September 25 announcement adds memory data to Sandbox observability. The overview card shows average, P75, and P95 usage beside CPU and data transfer. On an individual sandbox, the chart scales to that sandbox's limit and marks 85 percent with a dashed line.
The same data is available in the Query builder as the `memoryUsedBytes` measure on sandbox usage events. The CLI exposes `vercel.sandbox.memory_used_bytes` through `vercel metrics`. A linked project returns project data; `--all` aggregates projects across the team. CLI output includes the period, interval, project, and min, max, and average values.
The new metric closes a gap in the existing Sandbox view
Vercel added more granular Sandbox observability in July, including active CPU, provisioned memory, data transfer, running sandboxes, and sessions. Provisioned memory shows the capacity reserved over time. The new measurement shows bytes actually used. Teams can now compare the box they bought with the memory a workload consumed.
Imagine a coding agent that installs dependencies, starts a dev server, runs tests, and captures a browser preview. Provisioned memory cannot reveal whether the test phase approaches the ceiling. Actual usage can. If P95 rises only during browser tests, the team has a much narrower investigation than “the agent is unstable.”
| Signal | Useful question | What it cannot prove alone |
|---|---|---|
| Memory used | Which sessions approach their configured ceiling? | Why memory grew or whether the task succeeded |
| Provisioned memory | How much capacity was allocated over runtime? | How much of that capacity was actually needed |
| CPU usage | Which stages perform sustained computation? | Whether waiting, memory, or an external tool caused failure |
| Session and transfer data | When did work run and move data? | Whether the generated result was correct or useful |
Seuil analysis: segment memory by task before changing capacity
A team average can hide two different products. Short extraction jobs may stay flat while code-generation sessions climb when they launch a browser. Group by project, sandbox name, session, workflow type, and release where the available fields allow it. Then compare normal and failed runs over the same task stage.
Use percentiles to find shape, not just size. If average memory is calm and P95 jumps, investigate a rare input, leaked process, parallel tool, large repository, or unusually long session. If average and P95 rise together after a release, a systematic change is more plausible. Neither pattern proves the cause, so inspect logs, traces, process data, and the input behind the session.
This is the same discipline required for an AI proof of concept: infrastructure metrics only matter when attached to a user task and an acceptance result. A session that stays below its ceiling but produces the wrong patch is healthy only in the way a perfectly fueled car can still be driving into a lake.
Treat the 85 percent line as a prompt to investigate
The detail chart's 85 percent line gives teams a shared visual cue. Vercel does not describe it as a guaranteed failure threshold, service-level objective, or universal alert recommendation. Memory behavior depends on runtime, process mix, garbage collection, cache, input size, and how long a session remains active.
Define a product-specific response. For example, a team might inspect every session that crosses the line, correlate it with task outcome, and only add an alert after it understands normal bursts. An image build may briefly need high memory and finish correctly. A gradual climb across idle steps may suggest retained processes or data.
Vercel's current Query documentation says editing custom queries requires Observability Plus on Pro or Enterprise, while free users can open but not modify queries. Confirm the team's plan, retention, granularity, and alert access before designing an operating process around a screenshot from another account.
Memory data should join quality, latency, and cost
Build one view of a completed task: session identifier, workflow, input class, model and tool versions, memory percentiles, CPU, duration, retries, result status, human corrections, and cost. That record lets a team ask whether a resource change improves accepted work rather than merely moving a line.
A hypothetical document agent may use more memory after adding a local index, but finish faster and reduce retrieval failures. That can be a good trade. Another change may increase memory because stale browser processes survive between steps while task quality stays flat. The second case needs cleanup, not a larger sandbox.
Connect the measurements to the outcome chain in Seuil's AI value analysis. Adoption, task behavior, outcome, and business effect remain separate layers. Infrastructure health supports them; it does not replace them.
The release still leaves important operating questions open
The announcement confirms the displayed aggregations, 85 percent reference line, Query measure, CLI metric, and alert creation from a chart. It does not publish a universal sampling interval, recommended alert threshold, memory overhead model, or rule connecting a percentile to an out-of-memory failure. Teams must validate those details against their plan and workload.
Memory observation also does not provide application-level recovery. A sandbox that fails halfway through an agent task still needs idempotent steps, saved progress, cleanup, retry limits, and a trustworthy result state. Persistent files, covered in the Sandbox Drives analysis, solve a different problem from memory telemetry.
What product teams should do now
- Record a session identifier, workflow type, release, input class, and final task outcome.
- Capture memory beside CPU, duration, retries, errors, human corrections, and cost.
- Compare average, P75, P95, and maximum by workflow instead of relying on a team average.
- Inspect sessions that cross 85 percent before turning the reference line into an alert.
- Test large inputs, browser-heavy stages, parallel tools, long runs, cleanup, and recovery.
- Confirm plan access, data retention, query granularity, alert delivery, and export needs.
Start with one bounded agent workflow and one week of instrumented runs. If you need to connect the resource data to evaluation and recovery, Seuil Digital's AI product work can help design the pilot before more capacity becomes the default answer.