Needs permission level 3: an operator on a server, or cheats enabled in singleplayer. Run /debug stop once you have captured 30 to 60 seconds.
Where the output file goesThe debug folder sits in the game directory: next to the saves folder (.minecraft) in singleplayer, or next to server.properties on a dedicated server. Minecraft creates it automatically the first time a report is written.
/debug is Minecraft's built-in tick profiler. /debug start begins recording what the server spends each tick on, /debug stop writes a readable report to the debug folder, and /debug function runs a datapack function with a line-by-line tracer attached.
Minecraft simulates the world in ticks, 20 of them per second, which gives the server a budget of 50 milliseconds per tick. When entities, redstone, chunk loading or datapack functions take longer than that, the tick rate drops and the game feels laggy. The profiler samples the named sections of the tick loop while it runs and reports what share of the time each one took, so you can see whether the problem is a mob farm, block entities, a specific dimension or something else entirely.
Because it is a diagnostic command, /debug needs permission level 3, one step above the level 2 that most cheat commands use. That means cheats enabled in singleplayer, op status on a server, and never a command block, since command blocks run at level 2. Typical uses: finding what is causing low TPS, measuring the cost of a farm before and after changes, and checking what a datapack actually executes.
When you run /debug stop, chat prints how many seconds and ticks were recorded along with the average ticks per second, and the full report is saved as a plain text file you can open in any editor:
In singleplayer the debug folder is created inside .minecraft, next to the saves folder; on Windows that is %APPDATA%\.minecraft\debug. On a dedicated server it appears in the server's working directory, next to server.properties. Note that the profiler measures the server side (the integrated server in singleplayer), so pure frame-rate problems on the client will not show up in it. A simple session looks like this:
1. Run /debug start during normal play, ideally near the build you suspect is causing lag.
2. Wait 30 to 60 seconds so the sampler averages over enough ticks.
3. Run /debug stop and note the ticks-per-second figure it prints; below 20 means the server is falling behind.
4. Open the profile-results file and follow the largest percentages down the tree, usually into the levels section for one dimension and its entities or blockEntities entries.
The command has exactly three forms. There is nothing to position or target; the only argument is the function ID in the third form:
/debug startStart the tick profiler. Let it record 30 to 60 seconds of normal play before stopping.
/debug stopStop profiling, print elapsed seconds, ticks and average TPS in chat, and write debug/profile-results-<date>.txt.
/debug function mypack:mainRun the function main.mcfunction from the mypack namespace with a tracer and write debug/tracing-<date>.txt.
/debug function #minecraft:tickTrace every function your datapacks register in the vanilla tick tag, the ones that run each game tick.
It runs Minecraft's built-in tick profiler. /debug start begins sampling what the server spends each tick on, /debug stop ends the session and saves a report file, and /debug function runs a datapack function with a tracer that logs every command it executes. It is a diagnostic command, so it needs permission level 3 instead of the level 2 most cheat commands use.
In a folder named debug inside the game directory. In singleplayer that is .minecraft/debug, next to your saves folder. On a dedicated server it is the debug folder next to server.properties. The tick profiler writes profile-results-<date>.txt and the function tracer writes tracing-<date>.txt; Minecraft creates the folder automatically the first time a report is written.
The report is a tree of named tick sections, each line showing the share of its parent section and of the whole tick, plus how often it ran. Follow the largest percentages downward. Lag sources usually show up inside the tick and levels sections for one dimension, under entries like entities, blockEntities or chunkSource, and the counts tell you how many objects were processed per tick.
/debug requires permission level 3, one step above normal cheat commands. In singleplayer you need cheats enabled, or reopen the world with Open to LAN and Allow Cheats on. On a server you must be an op; the default op-permission-level of 4 covers it. Command blocks run at level 2, so /debug can never run from a command block.
It runs a datapack function once with a tracer attached and writes every command the function executed, together with its result, to debug/tracing-<date>.txt in the same debug folder as the profiler reports. Point it at a function ID like mypack:main, or at a tag like #minecraft:tick to trace every function in the tag. It cannot be called from inside a running function, so run it directly from chat or the server console.
It is the best first step in vanilla: no mods needed, and the report points at the dimension and system eating your ticks. For a live number, /tick query prints the current average tick time. On modded or very busy servers, dedicated profilers such as the spark mod give deeper per-mod detail, but /debug plus the F3 + L client capture cover most vanilla cases.
Profiling pairs well with controlling the tick rate itself. Browse more Minecraft tools: