Profiles and Memory Reports on the Website — Diagnostics

Sending Them

Nothing leaves the server on its own: an operator sends one profile or one memory report at a time, with a command. There are two ways:

Command	What voxelbench.com receives	Where it ends up
`/bench profile upload <id>`, `/bench memory upload <id>`	The file as it is. The server must be linked	Your account, private, on every plan
`/bench profile share <id>`, `/bench memory share <id>`	A copy cleaned by the plugin. No account or linked server needed	A public, unlisted link, valid 7 days (see Public Share Links)

A server can upload 10 profiles and 10 memory reports per hour. The commands, preview and the cases where a send is refused are described in Profiling and Memory Inspection.

Where to Find Them

Dashboard → Profiles

Performance profiles lists the profiles of all your servers. Filter them by server, trigger (Manual, Ring buffer, After a lag), platform or profile id, and sort them by date sent, date captured, tick samples, window, profile id or platform. Each row gives the capture date, the window, the samples (tick and all), the platform, Java, the busiest owners and Kept until. Few samples marks a profile with too few tick samples for its percentages to be more than rough.

Once you pick a server, Evolution of this server opens its profiling history.

Dashboard → Memory

Memory reports lists the heap summaries and dump analyses of all your servers. Filter them by server, kind, mode or report id, and sort them by date, heap size, top plugin share, number of leak suspects or report id. Each row gives the heap, the plugin that holds the most, the number of suspects and Kept until. Once you pick a server, This server's Memory tab opens it.

The Server's Profiling and Memory Tabs

A server's monitoring dashboard has a Profiling tab and a Memory tab. Without monitoring, because it is off for that server or not in your plan, the same page still shows the profiling history and the memory reports next to the monitoring setup steps, once the server has sent one. You reach them from the lists above, and from History and evolution in the Performance profiles card of the server's Monitoring settings tab.

Profiling is the history of the server's profiles, made of their summaries (see How Long They Are Kept). It shows the latest profile, or the one you select: who used the tick, what the tick was spent on (entities, chunks, redstone, plugin code…), the busiest methods, warnings and key points, with Open the full profile while it still exists. Evolution charts, over 30 days, 90 days or a year, the share of the main plugins and of each kind of work, one point per profile; click a point to show that profile. Comparison puts two of them side by side.
Memory lists the server's memory reports, newest first, with the heaviest plugin and the number of leak suspects, and, on a monitored server, a Monitoring at that time link to the charts around that moment.

On a monitored server, the charts mark each uploaded profile and memory report with P and M, and the events table lists them as captures (see Monitoring Dashboard).

A Profile's Page

A profile's page states This profile is private: only you can see it. Its header gives the trigger, the window, the sampling period, the tick samples and all samples, the platform, the plugins, Java and the system; a profile captured after a lag says what kind of lag it was. Warnings follow, for instance too few samples or stacks cut short.

Where the tick time goes gives each plugin or component its share of the tick samples: Self, where it is the innermost code, and Incl., where it appears anywhere in the stack. Four views then explore the samples: Map (who weighs most, as areas), Tree (the path of the calls), Bottom-up (methods by their own time, with their callers) and Methods (a sortable table). You can search a class, a method or a plugin, filter by owner, focus on a branch and open the hottest path.

The buttons give All profiles, Compare with…, Raw JSON (the document exactly as your server sent it) and Delete. Deleting removes the profile and its summary from VoxelBench for good; the copy on your server is not touched.

What a profile measures, and its limits, are explained in Profiling. Keep in mind that these are shares of samples, never durations: a share that rose is not, by itself, the cause of a lag.

A Memory Report's Page

A memory report's page shows a heap summary or a dump analysis: the totals, Memory per owner, the heaviest classes, the class loaders and, for an analysis, the Leak suspects, the accumulation points, the Minecraft objects, duplicate strings and collections. The buttons give All memory reports, Compare with… (another report of the same server), Monitoring at that time (the server's charts from 30 minutes before to 30 minutes after the report, when they exist), Raw JSON and Delete, which removes the report from VoxelBench for good without touching the copy on your server.

How to read a summary and an analysis is explained in Memory Inspection.

How Long They Are Kept

Every plan can upload. The plan decides how many are kept and for how long:

Plan	Profiles	Memory reports
Free	5, for 30 days	5, for 30 days
Pro	50, for 180 days	50, for 180 days
Enterprise	200, for 1 year	200, for 1 year
Hosting provider	200, for 1 year	200, for 1 year

Past the number or the age, the oldest go first; nothing is archived. When your quota is full, the list marks the one that Goes at next upload.
A server keeps at most 50 memory reports, whatever the plan, so that one busy server does not push out the others.
A short summary of each profile is kept a year, on every plan, even after your plan's limits have deleted the full profile: it is what the Profiling tab and its evolution are made of. A summary holds shares of tick samples and counts, never a duration. When the full profile is gone, the tab marks it summary only and lets you Delete this summary.
Deleting a profile yourself deletes its summary too. Unlinking the server, or deleting your account, deletes its profiles, summaries and memory reports.

Comparing Two Profiles

Tick two profiles of the same server in Dashboard → Profiles and click Compare, or use Compare with… on a profile's page; the list there includes profiles that only have their summary left. Before is always the older profile.

The page first says whether the two captures compare: Comparable captures, Compare with care or cannot be compared reliably, with the reasons: different triggers, platforms or versions, very different windows, too few samples.
Owners, kinds of work and busiest methods are then compared in points of share of the tick samples, with a status (new, gone, up, down, stable, unknown) and Key points.
When both full profiles still exist, every owner and 30 methods are compared. Otherwise the comparison uses the summaries: at most 10 owners and 10 methods per profile, and one outside a list has an unknown share.
Noise is a rough estimate of sampling noise; the real noise is larger. A change inside it is no evidence.

Comparing Two Memory Reports

Tick two reports of the same server in Dashboard → Memory and click Compare, or use Compare with… on a report's page. The older snapshot is the base, and every change reads newer minus older.

The page says what compares: Directly comparable (same tool, same measure), Partly comparable (only what both reports measure) or Indicative only (two different tools), and why, for example a heap summary against a dump analysis, or live objects against all objects. A growth between two snapshots is not proof of a leak: a cache filling up or a world loading looks the same. Confirm it with the heap after GC over several hours, then with a later full analysis.

The API reads and compares profiles and memory reports too, for the owner only, with the monitoring:read scope (see API and Tokens and Connect Claude to Your Account).

/bench profile share and /bench memory share publish a cleaned copy behind a link such as voxelbench.com/p/… for a profile or voxelbench.com/m/… for a memory report.

Who can open it: anyone who has the link, without an account, for 7 days. Nothing lists it, and search engines are asked not to index it. After 7 days the link stops working and the copy is deleted.
What it shows: the same views as a private page, under a banner giving the expiry date, and a count of the names the plugin cleaned. It shows no server, owner or account, and voxelbench.com keeps none of them with the share. It has no Raw JSON download.
It is not in your account: a share belongs to no account and appears nowhere in your dashboard. To delete it before it expires, run /bench profile unshare <id> or /bench memory unshare <id> on the server, even after deleting the local file.
Report: anyone who sees a shared page can report it; an administrator reviews it and may remove it.
Only official VoxelBench builds can share.

Privacy

A heap dump never leaves the server. It holds everything the server had in memory, the link token included. No command, button or automatic path sends one; only the summaries and analyses made from it can be sent (see Memory Inspection).
An upload is the file as the plugin wrote it, private to your account. A profile holds plugin, class, method and thread names, which reveal your plugins, private ones included; a memory report holds class, field and plugin names, sizes and counts, never a value from the heap.
A share is a copy the plugin cleans before sending. It replaces IP addresses, host names, URLs, email addresses, file paths, UUIDs, long hexadecimal strings and the names the server knows (online players, worlds other than the default ones, the machine's user and name, the server folder, its id and link token) with a marker such as [ip], and leaves out any field it does not know to be safe. A memory report's share also rounds its date to the hour, removes the machine's memory figures and rounds heap sizes. Plugin names stay: they are what makes the copy useful to whoever helps you. The details are in Profiling and Memory Inspection.