How I stopped my Creative maps from timing out mid-game
I spent about three weeks debugging a map where the scoreboard would randomly show stale data, then another week realizing the problem wasn't the variables at all. It was the logging system. Specifically, how I was using the Fortnite Creative Logbook to track round wins, eliminations, and match events. Here is what actually works.
Setting up the Fortnite Creative Logbook for tracking events
Start by placing a Logbook device on your island through the Creative inventory. Once it is placed, open its settings panel and you will see options for what the device logs. The default settings capture basic interactions, but most of what you actually need requires enabling specific event types. I recommend turning on Player Interactions, Device Triggers, and Custom Events. Leave "Environment Events" off unless your map explicitly needs weather or map-object tracking — that category bloats the log and slows performance. The key field is the Log Limit. By default it sits at 50 entries. That number is usually too low for anything longer than a single quick match. I set mine to 200 on maps that run extended rounds, and 100 for single-round maps. Going above 300 does not give you extra utility and it noticeably increases device memory overhead. That number is based on testing, not an official guideline from Epic, but the drop-off in performance after 300 is consistent enough that I have never seen a reason to go higher. After configuring the Logbook, you need a way to read the log entries. Place a second device — either another Logbook or a simple Datastore device — and use the "Read Log" action from the device editor. This pulls the most recent entries from the Logbook. The action has a small but important detail: it reads the log in reverse chronological order by default, meaning the newest entry comes first. If your map logic expects the oldest entry first, you have to manually adjust the index or use a loop to flip the sequence.
One thing beginners miss is that log entries do not automatically clear between rounds. If you are running a tournament-style map with multiple rounds, the log from round one stays in the device until you either set the Log Limit low enough that old entries get overwritten, or you explicitly clear the log using the "Clear Log" action between rounds. I used to forget this step and then spend an hour wondering why the win counter was adding round three's elimination to a total that should have been reset. The workaround is simple: place a Clear Log action on the round-start trigger. Takes about three seconds to set up and saves hours of debugging.
Get the Full Details
The part nobody explains about log latency
When a player triggers an event, the Logbook does not record it instantly from the server's perspective. There is a delay of roughly one to three seconds depending on how many other devices are firing at the same time. On a small island with five or ten devices active, the delay is almost unnoticeable. On a large arena with fifty-plus devices all responding to the same trigger, the log entries can be out of order or delayed by five seconds or more. This is not a bug. It is how the replication pipeline works. I learned this the hard way on a capture-the-flag map. The flag capture event logged correctly, but the scoreboard update fired before the log entry existed, so the score display would show the old value for a few seconds after a capture. The fix was to use a small delay — two seconds — on the scoreboard update action after the flag capture trigger. That gave the log enough time to register before the score read it. Another thing to watch for: if you have multiple Logbook devices on the same island, they do not share data. Each one maintains its own separate log. I once built a map with three Logbooks scattered across the island, assuming they would aggregate into a single feed. They did not. I had to consolidate everything into one device and route all triggers to it instead. If you need multiple tracking points, consider using a single Logbook and tagging entries with custom labels or categories so you can filter them later when reading the log.
When the Logbook fails and what to do instead
The Fortnite Creative Logbook is useful for tracking events, but it is not a reliable data persistence tool. If your map requires exact, immutable records — like a competitive tournament result that must survive a server restart — the Logbook is the wrong choice. It stores data only in the current session. Restart the map, and the log resets to empty. There is no export function, no external storage option, and no way to retrieve old logs after the session ends. For persistent data across sessions, use a Datastore device paired with a web API or a third-party database. This adds complexity but is the only way to guarantee data survives beyond the current match. I have used a combination: the Logbook for in-match event tracking and quick diagnostics, and Datastore for anything that needs to last after the game ends. The Logbook setup takes about ten minutes. The Datastore integration takes longer, maybe forty-five minutes to an hour for someone who has never done it before, but it pays off if you need permanent records. If you are building a casual map and do not care about post-match data, the Logbook is perfectly adequate. Set it up, wire your triggers, and move on. But do not assume it is a full-featured database. It is a log. It logs things in order. That is it. Everything else is extra work around its limitations.
