Clearing and Monitoring Laravel Telescope Entries

You’re debugging a production issue. You open Telescope and type the job ID from your error logs. Nothing appears. You search for the request ID. Nothing. You check the entries table directly. The job ran. The request was logged. The entry exists, but it’s not showing up in the dashboard because Telescope truncated the display at 50 entries per page and you’re on page 47. You scroll. It loads. The entry is there. Everything is fine.

Except: on a different day, you search for an entry and it genuinely isn’t there. It should be - the job ran, the error fired. But Telescope shows nothing. You check the table directly. The entry exists. It’s a live entry, captured by Telescope’s real-time broadcaster. On this server, the WebSocket connection dropped three days ago and nobody noticed.

There’s a less obvious Telescope failure mode: the data is in the database, but Telescope can’t reach it.

What telescope:clear Does

telescope:clear is a hard delete. It removes all entries from all Telescope tables:

php artisan telescope:clear

This is not a soft delete. There’s no deleted_at column. It removes the data permanently. The command truncates:

• telescope_entries
• telescope_entries_tags
• telescope_entries_commands
• telescope_entries_queries
• telescope_entries_models
• telescope_entries_jobs
• telescope_entries_batches
• telescope_entries_cache
• telescope_entries_notifications
• telescope_entries_events
• telescope_entries_http
• telescope_entries_logs
• telescope_entries_mail
• telescope_entries_notifications
• telescope_entries_schedules
• telescope_entries_exceptions

It uses DB::table('telescope_entries')->truncate() internally, which is instantaneous and releases disk space immediately. This is different from telescope:prune, which deletes in chunks.

You would use telescope:clear in these situations:

• After a development or staging environment where Telescope accumulated thousands of entries during testing
• After a bulk data migration that generated thousands of irrelevant entries
• When you want to free disk space immediately rather than waiting for prune to catch up
• In CI pipelines where Telescope is enabled for debugging but shouldn’t persist between runs

Common Failure Modes

Clear runs accidentally in production. If telescope:clear is in your deploy pipeline or accidentally scheduled in production instead of development, you lose all historical Telescope data. Unlike telescope:prune, there’s no age filter - it wipes everything. The command has no confirmation prompt when run non-interactively. If your deploy script calls php artisan telescope:clear with the wrong environment variable, your production history is gone.

Clear while a developer has Telescope open. The Telescope dashboard maintains a live connection via Horizon’s broadcast system. When telescope:clear truncates the tables, the live entries vanish from the dashboard in real time. If a developer is actively debugging a live issue, they lose the real-time view of what’s happening.

Prune and clear running together. If you have both telescope:prune and telescope:clear scheduled (e.g., clear weekly, prune hourly), a conflict can occur. The hourly prune deletes entries in chunks. The weekly clear truncates everything. If they run simultaneously, the truncate may fail with a lock timeout, or the prune may delete entries that a concurrent clear is trying to process.

Clear doesn’t fix the WebSocket gap. The data is in the database. The dashboard can’t show it because the real-time WebSocket feed was interrupted. telescope:clear won’t fix a broken Horizon WebSocket connection. You’ll need to restart the Horizon worker to restore live monitoring.

Building Visibility Into Telescope Data

The health check for Telescope is not about whether entries exist - it’s about whether the database and the live feed are both functioning:

Schedule::call(function () {
    // Count recent entries (last 5 minutes)
    $recentCount = DB::table('telescope_entries')
        ->where('created_at', '>', now()->subMinutes(5))
        ->count();

    // Count total entries
    $totalCount = DB::table('telescope_entries')->count();

    // Log for trend analysis
    Log::info('Telescope data check', [
        'entries_last_5_min' => $recentCount,
        'total_entries' => $totalCount,
    ]);

    // Alert if no new entries in 5 minutes on a busy app
    // (but be careful - not all apps generate entries constantly)
    // This is most useful on apps with steady request volume
    if ($recentCount === 0 && now()->hour >= 9 && now()->hour <= 17) {
        // Daytime hours with no entries - might indicate Telescope stopped capturing
        Http::get(env('CRONTINEL_TELESCOPE_ENDPOINT'));
    }
})->everyFiveMinutes();

When to Use clear vs prune

In production, use telescope:prune on a schedule. Use telescope:clear manually and rarely.

Quick Setup with Crontinel

For production, configure prune only:

// routes/console.php
Schedule::command('telescope:prune', ['--hours' => 24])
    ->everyFifteenMinutes()
    ->withoutOverlapping()
    ->onOneServer();

Monitor Telescope’s overall health - whether it’s receiving and storing entries at all:

Schedule::call(function () {
    $recent = DB::table('telescope_entries')
        ->where('created_at', '>', now()->subMinutes(10))
        ->count();

    if ($recent === 0) {
        // No new entries in 10 minutes during business hours
        // Could mean Telescope stopped capturing
        Http::get(env('CRONTINEL_TELESCOPE_ENDPOINT') . '/no-entries');
    }
})->everyTenMinutes();

If you do need to run telescope:clear in production (say, after a bulk operation generated garbage), do it manually during low-traffic hours and monitor that Telescope resumes capturing entries afterward. The resumption of entries is your confirmation that the clear completed and Telescope is back to normal.

Telescope’s value is in the data. Without monitoring, you won’t know the data is gone until you need it.