Sample Specific Transactions

If you want to sample specific Transaction, use the traces_sampler option:

    'dsn' => '',
    'traces_sampler' => static function (\Sentry\Tracing\SamplingContext $context): float {
        if (false !== strpos($context->getTransactionContext()->getName(), 'health')) {
            // Discard transactions that have 'health' in their name
            return 0.0;
        // Sample rate for all other transactions
        return 1.0;

You can also define traces_sampler as a callable that receives a \Sentry\Tracing\SamplingContext $context which should return a float (for the sample rate):

'traces_sampler' => array('App\Helpers\General\TracesSampler', 'sample')

Instrument HTTP Calls

To instrument HTTP calls using GuzzleHttp, you'll need to add a handler to your Guzzle Client, which we provide within our SDK. Here's an example of it use:

$stack = \GuzzleHttp\HandlerStack::create();

// This is the important line
// ----

$client = new \GuzzleHttp\Client([
    'base_uri' => '',
    'timeout'  => 2.0,
    'handler'  => $stack
$client->request('GET', '/get');

After adding this handler, you will receive spans for every request from this client.

Custom Instrumentation

To instrument certain regions of your code, you can create a transaction to capture them.

$transactionContext = new \Sentry\Tracing\TransactionContext();
$transactionContext->setName('External Call');
$transaction = \Sentry\startTransaction($transactionContext);

$spanContext = new \Sentry\Tracing\SpanContext();
$span1 = $transaction->startChild($spanContext);

// Calling functionX


Retrieving a Transaction

If you want to attach Spans to an already ongoing Transaction, you can use \Sentry\SentrySdk::getCurrentHub()->getTransaction(). This function will return a \Sentry\Tracing\Transaction if there is a running Transaction on the scope, otherwise it returns null.

$transaction = \Sentry\SentrySdk::getCurrentHub()->getTransaction();

if ($transaction instanceof Transaction) {
        'action' => $route->getActionName(),
        'name' => $route->getName()

You can also use this to filter for specific conditions when you don't want to send a \Sentry\Tracing\Transaction. This example illustrates how:

$transaction = \Sentry\SentrySdk::getCurrentHub()->getTransaction();

if ($transaction instanceof \Sentry\Tracing\Transaction) {
    // $transaction->setSampled(false); // __DONT__ SEND TRANSACTION
    // $transaction->setSampled(true); // __DO__ SEND TRANSACTION

Improve Response Time

Using the performance capabilities of PHP has some impact on your response time (depending on the traces_sample_rate you configured). Because of the nature of PHP, requests in most cases are sent in the same process as you serve your users' response. In sum, this process affects the time it takes to send a request to Sentry, as it is added on top of your servers' response time. To mitigate this and reduce the addition close to zero, you can use a Relay running locally on the same machine or local network that acts as a proxy/agent. As a result, instead of your PHP process sending things to Sentry, the PHP process sends it to your local Relay, which then forwards it to Sentry.

To begin using Relay, review our content for Getting Started.

Currently, we recommend using Relay in managed mode (which is the default). Then follow the instructions in the Relay docs to send a Test Event via Relay to Sentry.

Don't forget to update your DSN to point to your running Relay instance. After you set up Relay, you should see a dramatic improvement to the impact on your server.

Connecting Services

If you are also using Performance Monitoring for JavaScript you can use a helper function to continue the trace started from your backend in order to connect services. Add the following line to your blade template rendering the <head/> of your page.

{!! \Sentry\Laravel\Integration::sentryTracingMeta() !!}

This helper function will render a meta tag similar to this <meta name="sentry-trace" content="49879feb76c84743ba5034bd2d3f1ca3-7cb5535c930d4666-1"/> which our JS SDK will pick up and continue the trace. Therefore your frontend and your backend are connected via the same trace.

Otherwise other backend services with Performance Monitoring will connect automatically.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").