Laravel Pulse Custom Recorders for API Monitoring

During our last sprint, we faced a silent killer: a third-party payment gateway that was intermittently hanging for roughly 3.2 seconds. It didn't trigger any 5xx errors, so our standard uptime monitors stayed green, but our customers were seeing "Processing..." spinners for an eternity. We needed deeper insight into our outbound traffic, and that’s when I decided to leverage Laravel Pulse to track these requests directly from our app.

Building Custom Recorders for API Monitoring

Standard observability tools often miss the nuance of application-level latency. While I've previously used Kubernetes Observability: Implementing Distributed Tracing with Tempo for cross-service debugging, sometimes you just need a lightweight dashboard inside your Laravel admin panel.

Pulse is perfect for this. Instead of bloating our infrastructure with heavy tracing agents, I built a custom recorder to sample outgoing HTTP requests.

The First Failed Attempt

I initially tried to hook into the Illuminate\Http\Client\Events\ResponseReceived event. It seemed logical—capture the start time, capture the end time, and ship it to Pulse. The problem? It didn't account for connection timeouts or DNS resolution issues. I was measuring the "response" time, but ignoring the time it took to actually establish the socket.

I had to pivot to a decorator pattern for our HTTP client. By wrapping the Illuminate\Http\Client\Factory, I could capture the entire lifecycle of the request, including the time spent waiting for the handshake.

Implementing the Recorder

To implement Laravel Pulse custom recorders, you need three main components: a Recorder class, a Card component, and a Livewire component. Here is how I structured the recorder to track our payment gateway latency:

PHP
namespace App\Pulse\Recorders;

use Illuminate\Support\Facades\Http;
use Laravel\Pulse\Pulse;

class ExternalApiRecorder
{
    public function record(string $apiName, float $duration)
    {
        Pulse::record('api_latency', $apiName, $duration);
    }
}

By injecting this into our API client, I could send metrics directly to the Pulse storage driver. Since we’re already optimizing our infrastructure—much like how we improved network efficiency by Implementing Kubernetes NodeLocal DNSCache for Lower DNS Latency—it felt natural to extend this performance-first mindset to our third-party integrations.

Performance Profiling with Custom Recorders

Once the data was flowing, the dashboard revealed that 14% of our requests were taking over 800ms, which is unacceptable for a synchronous payment flow. I used the Pulse aggregate methods to keep the data footprint small. You don’t want to store every single request; you want the p95 and the average.

When you're diving into API monitoring, don't just log the status code. Log the service name, the endpoint, and the duration. If you're looking for broader patterns, remember that Laravel Trends: Supercharge Your Development often points toward these kinds of small, high-impact observability wins.

Why Custom Recorders Matter

Using Laravel observability tools effectively means knowing what not to track. I don't need to track internal database queries in Pulse—that's what our APM is for. But for external APIs? Pulse gives us a "sanity check" dashboard that anyone on the team can view without needing access to our Grafana or Tempo instances.

FAQ

Can I use Pulse recorders for non-HTTP events?

Yes. Pulse is just a data aggregator. You can record anything—queue processing times, file system write latency, or even the time taken to generate a PDF.

Does this add overhead to my requests?

Minimal. If you use the Pulse::record helper, it writes to a temporary buffer or a Redis stream. It won't block your main thread unless your storage backend is severely misconfigured.

What happens if the API is down?

Your recorder should handle exceptions gracefully. Don't let a failing API monitor crash your production request. Use a try-catch block inside your recorder logic.

Final Thoughts

I'm still not 100% satisfied with our sampling rate. We're currently sampling 100% of production traffic, which is fine for now, but as our request volume grows, I might need to implement a probabilistic sampler to avoid hitting our Redis memory limits. I'm also considering whether to move these metrics into a dedicated time-series database if we decide to keep the history beyond the default 7-day window. For now, it’s working, but it’s definitely a piece of the architecture I’ll be watching closely during our next load test.