Server Log History (Released)

The developer console is wonderful, but it has 4 big weaknesses:

  • You can only view logs that have been created since you joined the server
  • You can’t view others’ client logs (only your own) making it harder to debug issues other clients are having
  • It’s impossible to filter out garbage warnings/errors (e.g. “Replication: Can’t create default object of type x”)
  • It’s difficult to manage substantial amounts of duplicate errors/warnings

As I’ve needed to debug Zombie Rush issues, I wanted to get around these weaknesses. To do that, I’ve made my own server log history:

Here’s a brief look at the interface:

If you remember, I wasn’t a fan of those garbage warnings, so after a couple filter additions, here’s the server log:

I’m also able to view other clients’ logs as I mentioned earlier (and all of these are from before I joined the server):

I can also open up the stack trace by clicking the detail button at the bottom of the frame (you’ll also notice that those three errors have occurred more than once but have been combined):

The first release can be found here: Log Tracker - Roblox

This is lacking some features I’d like to include in a final release, but it’s still extremely useful in it’s current state, and there are no breaking bugs (mostly UX issues). Here are the following changes you can look forward to in future versions:

  • Combine similar logs instead of local logs
  • I currently combine logs for players/characters/UserId (e.g. Players.EchoReaper.Backpack and Players.Guest.Backpack both become Players..Backpack), but other similar logs are not combined
  • Allow custom filters through the UI (currently has to be done through Lua)
  • Separate HTTP errors into their own tab? (currently all blocked)
  • Most of these errors are garbage, but if your game starts to see things like characterappearances not loading these might be a good thing to have

To use Log Tracker, require it either by ID (gets automatic updates) or take the (free) module, insert it into your game, and require that (opt out of automatic updates). From there, you can use F8 or chat “/log” to open it. I’ve also included a few API members that can be used so there’s no need to modify the module itself (makes it easier to update to later versions). Here are the current members:

Log Tracker isn’t able to be used by everyone (security reasons – it’d be bad if people could see how your scripts are breaking and potentially use that to their advantage) – by default, only the place owner can open it. If it’s a group place, only the group owner can open it – if there’s an easy way to check whether someone has place edit permissions for a group, let me know and I’ll change it to allow all players with place edit permissions.

Using this method, you’re able to specify your own callback to be used to decide who has access to Log Tracker. callback is a function that takes a parameter of player and returns true/false depending on whether they should have access to Log Tracker or not. Example usage:

    return player.UserId == game.CreatorId --Only the creator has access to Log Tracker

Log Tracker has a blacklist that allows you to ignore specific, usually garbage, logs. If the log contains something in the (case-sensitive, string-only) blacklist, it won’t be logged. The default list is:

  • onSoundLoaded cannot find
  • We already gave out badgeId
  • Replication: Can’t create default object
  • failed to learn
  • could not fetch
  • Image failed to load
  • Sound failed to load
  • ContentProvider:Preload() failed
  • http
  • HTTP
  • CURL

Example code to set the list to something else (must be a table and must only contain strings):

logTracker:SetBlacklist({"My custom blacklisted phrase"})

The blacklist exemptions offer more power than just the blacklist. If a log message contains a phrase in the blacklist exemptions, even if it also contains a phrase in the blacklist, it will be logged. This can be useful for logging specific errors/warnings that contain generic keywords like “http” but also contain unique identifiers like “404”. The usage and restrictions are the same as SetBlacklist.

#logTracker:AddToBlacklist(table or string)
Instead of completely overwriting the default blacklist, you can add your own phrases to the default with this method. Example usage:

logTracker:AddToBlacklist({"fooey", "gooey"})

Like the previous two methods, the table must contain only strings.

#logTracker:AddToBlacklistExemptions(table or string)
This adds the given string/table of strings to the blacklist exemption list. Its usage and restricts are the same as AddToBlacklist.

Some more info I’d like to add since proper UX isn’t in place yet:

  • You can sort logs by clicking the column titles
  • You can invert the sort by clicking the same column title twice
  • Clicking “Log Message” sorts by chronological order (by when the first time the error/warning was logged – not the latest)
  • If sorting by Receivers/Occurrences and the values are equal, the logs will be secondarily sorted by chronological order
  • Receivers means the total number of clients who received the error. Occurrences means the total number of times that error has been logged. 2 receivers and 10 occurrences means that that error has been experienced by 2 people and they collectively generated that error 10 times (could be 1 time for PlayerA and 9 for PlayerB or 5 for each – it’s not specific)

This is pretty, I like it.

Does it save server log history between servers? Say if a server shuts down and is gone, if you join the game and create a fresh server, will you still be able to read logs from the previous server? (essentially actually saving the logs). This might be problematic for games with multiple servers though.

Also, kind of a personal irrelevant feature I would find useful, think you could implement chat logs that save history?

No. I could save the logs to DataStores, but one of the things I really don’t want is my log history generating it’s own errors.

I considered this, but couldn’t think of any use cases related to the goal of the project. If you want to review the chat for moderation purposes, that’s not within the scope of the project. If you want to read the chatlogs to find if players are talking about bugs/feature requests, you’re better off with a dedicated in-game bug/feature request reporter, and that’s an entirely different project on its own.

I’m a clanner, and personally chatlogs is for my own will to gather information from visitors to our bases, be it friend and foe. I like to see what people have to say about my places, too.

This is amazing.

1 Like

This looks extremely useful. Do you have an estimate on release?

Maybe by the end of today or tomorrow.


Ever want to know your real average playtime that isn’t affected by people joining and leaving seconds later (whether it be due to server hopping, connection issues, etc)? I’ve included a trimmed average stat in the GUI that ignores outliers:


Protip: cumulative*


Whew. The biggie is out of the way: The same error across multiple clients is now combined into one:


Still on track to publish it today? This could come in handy with a plethora of problems I seem to be having all of a sudden.

1 Like

I’ll publish tonight just because there aren’t any issues that make it unusable, but you may not see some of the features/fixes I have planned until later. I think I’ll publish it as a (public) MainModule so that way users can opt in to automatic updates, but also have the ability to opt out in case they’re not a fan of someone being able to remotely update things in their game.

This might expand before tonight, but this is the current game plan (I’m not sure where I’ll be by release):

(FYI stack traces aren’t specifically wrong, but they have unrelated stuff tacked on sometimes)

1 Like

With the update to stack traces, not only is unrelated stuff being included fixed, but it’s also smart enough to group stack traces, hide duplicates, and show different ones (it used to hide duplicate messages regardless, which meant if you had two different stack traces, but they shared one or more lines, those lines would be omitted from the second stack trace):

The first release is out! Check the updated OP for more info.

@TwentyTwoPilots @Tinarg


u the realest


This is so useful for debugging client-side errors which I can not replicate!

wow this is really useful, glad it got bumped

1 Like

Goodbye f9!
Looks like I will be using this from now on

1 Like

Works great, what would be even cooler is if it had the ability to connect it to a webhook and get all server/client logs there.

I think adding that would motivate people too much to use it in conjunction with Discord, so that seems like a bad idea. (Discord webhooks are not intended for event logging, it’s against their TOS)