Although Telescope's main use case is for local development, you can also use it as a lightweight monitoring system for your app in production. So let's take a look at that. So first I am going to php artisan migrate:fresh and get rid of all of these entries. Okay, so this should be empty now. Let's take a look at the TelescopeServiceProvider. And I showed you this already, but for local, it logs everything. But if it's not in local development, so in our case, let's change it to production. Let's say production here. Then it's only going to log these entries.

Or it's forbidden, because we have to set something in the Telescope service provider. And that is this gate here. So we can only access the Telescope route if we're logged in as a certain User. So I'm just going to hard code the User that I have there, so user.user.com. So obviously, this would be some sort of admin, so they can view the backend of Telescope. So let me just log in as that User, so we can see the dashboard again. Okay, so let's log in, and now we should see the Telescope dashboard again. And like I said, there are no requests here, because they are no longer being logged. So like I said, exceptions are still being logged up here. Exceptions, failed requests.

Okay, and they do. So if you want to use this as a way to monitor your exceptions, you can do that. What else here? So you're not limited to just these. You can add your own if you want. So say, for example, you wanted to use Telescope as a log viewer. So right now, logs are not being logged. So if I hit the log route, this will not show in the Telescope dashboard. Okay, so it was logged, and it is in the log, but it's not going to show here. So if you didn't want to show, you can modify this entry here and add another one for logs.

Okay, so it was logged, and it is in the log, but it's not going to show here. So if you didn't want to show, you can modify this entry here and add another one for logs. So if we take a look at the incoming entry, there is no check for if it's a log, but we can define our own. So let's go to definition, and you can see that there is a type here, and it's public. So let's go ahead and just dump the entry type here. Dump entry type. Now if I hit that log route again, you'll see that there are a whole bunch of entries here, like queries. But the one we're interested in is the log.

here, like queries. But the one we're interested in is the log. So back to the code, we can add another or clause here for logs. So I can say entryType because it's public, and we can say log here. But there's actually an enum that it's using. So if you look at incomingEntry, you'll see some enums being used here. Where's one here? Right here. So instead of a string, it's just using an enum, and we can do that as well. So let's grab this, and let me just show you.

So instead of a string, it's just using an enum, and we can do that as well. So let's grab this, and let me just show you. There's one for log here. So entryType, log, instead of using a string. So let's do that in here. Let's say entryType log, and let's make sure to import that. And now it should log our logs, and we can use Telescope as a log viewer if we want. So now let's hit that again. Let me get rid of that dump first. Let's get rid of this, and let's hit our logs route again.

Let me get rid of that dump first. Let's get rid of this, and let's hit our logs route again. And now hopefully this should work. And it does. Cool. What else here? So monitor tags. So right now, like I showed you, it's not logging everything like it did in local development. But if you're monitoring a tag, then it will log that information. So for example, for tags, you can tag any model here, but a useful one would be to tag

But if you're monitoring a tag, then it will log that information. So for example, for tags, you can tag any model here, but a useful one would be to tag or to monitor a logged in User. So to do that, let's add one, and let's say off 1. So now anything that this userId does will be logged. So this can be useful for debugging purposes. Say that User is having issues, you can monitor that User. And now since I'm logged in as 1, or I'm not sure if I'm still logged in, I am. Now the requests are being logged because we are monitoring off 1. So for the profile, we'll see all of that stuff appear in requests and everywhere else.

Now the requests are being logged because we are monitoring off one. So for the profile, we'll see all of that stuff appear in requests and everywhere else here where the User is logged in or where the User is tagged. So yeah, you can definitely make use of Telescope as a lightweight monitoring system for your app in production. But make sure to prune your entries. So where's that? Make sure you run this command on a schedule, because as you imagine, this can get quite large with all the entries going into the database. For example, all the requests that happen if you have a lot of users in your application.

large with all the entries going into the database. For example, all the requests that happen if you have a lot of users in your application. So yeah, just run that command. Was it php or php artisan telescope:prune? And the default is it will get rid of any entries longer than 24 hours, or you can specify your own time here. So this is not going to do anything now because none of the entries are greater than 24 hours. Oops. php or php artisan telescope:prune.