Scout supports Laravel 5.5+.

1. Install the scoutapp/scout-apm-laravel package:

composer require scoutapp/scout-apm-laravel

Note that the scout-apm-php package will automatically be included. It does not need to be installed directly.

2. Install the scoutapm php extension (optional, recommended):

sudo pecl install scoutapm

Several instruments require the native extension to be included, including timing of libcurl and file_get_contents. For more information, or to compile manually, the README has additional instructions.

3. Configure Scout in your .env file:

# Scout settings

If you’ve installed Scout via the Heroku Addon, the provisioning process automatically sets SCOUT_MONITOR and SCOUT_KEY via config vars. Only SCOUT_NAME is required.

4. Add the config/scout_apm.php

php artisan vendor:publish --provider="Scoutapm\Laravel\Providers\ScoutApmServiceProvider"

5. Clear and re-cache your config:

php artisan config:cache

6. Deploy.

It takes approximatively five minutes for your data to first appear within the Scout UI.

Code Based Configuration

If for any reason you can’t use environment based configuration, or it’d simply be easier to manage Scout in code, you can configure Scout with a Laravel config file. First ensure you have the config/scout_apm.php file created in step 4 above:

php artisan vendor:publish --provider="Scoutapm\Laravel\Providers\ScoutApmServiceProvider"

Then add any keys you want to override to the bottom of the file, following the template. The keys should be in lower case, with no prefixed SCOUT_. Any keys not mentioned will continue to be read from the environment.

$config['name'] = 'Overriden Name';

Finally, deploy and remember update any cached configs.


Scout automatically inserts its middleware into your application on Laravel startup. It adds one at the very start of the middleware stack, and one at the end, allowing it to profile your middleware and controllers.


Scout will work in Vapor (serverless) environment in the same way it does a persistent environment. No additional configuration is needed other than following the steps above


For low throughput applications, when the execution environment freezes, the core agent (which aggregates requests for a minute then sends them to our servers) won’t be able to send the payloads. During the next thawing, the core-agent will send the payloads it has had for previous times. This can lead to delays in ingestion time

Further, we have a 10 minute checkin window where we accept payloads. If the next invocation of the enivornment (thawing) occurs after 10 minutes, we won’t ingest the previous payload