Laravel health checks in productie: wat /up wel en niet bewijst

De standaard /up-route bevestigt dat Laravel zonder boot-exceptie opstart. Dat is geen bewijs dat een formulier mail kan versturen, een betaalprovider bereikbaar is of een klantportaal de juiste data toont. Gebruik aanvullende controles alleen voor afhankelijkheden die de bedoelde beschikbaarheid echt bepalen.

Storingsvergelijking: een bootfout kan /up laten falen; een defecte specifieke formulierflow kan bestaan terwijl /up succesvol blijft. Maak daarom onderscheid tussen een lichte bereikbaarheidscheck en een veilige test van een zakelijke flow.

• Controleer welke afhankelijkheden de health-route werkelijk aanspreekt.
• Geef externe controles korte limieten zodat de controle zelf geen storing versterkt.
• Gebruik geen echte klanttransactie of onbeveiligde diagnostische output als publieke health-check.

• Bron en verdere uitleg
• Laravel audit en technische hulp

Een Laravel-applicatie die HTTP 200 teruggeeft op een health endpoint is bereikbaar, maar dat bewijst niet dat de volledige toepassing bruikbaar is. De ingebouwde health route is vooral een lichte bootcheck. Voor productie-monitoring is dat een sterk vertrekpunt, zolang bereikbaarheid, kritieke dependencies en echte gebruikersflows apart worden bewaakt.

Wat `/up` wel en niet bewijst

Laravel 13 heeft standaard een health route, meestal op `/up`. Volgens de officiële documentatie geeft die 200 terug wanneer de applicatie zonder exception kan booten en 500 wanneer dat niet lukt. De route dispatcht ook `Illuminate\Foundation\Events\DiagnosingHealth`, zodat je gerichte extra checks kunt toevoegen.

• 200 op `/up` betekent dat Laravel de health request kon verwerken en booten.
• Een timeout of verbindingsfout kan vóór Laravel zitten, bijvoorbeeld bij DNS, TLS, webserver, netwerk of hosting.
• Een groene `/up` bewijst niet automatisch dat mail, een externe API, checkout of andere businessflow werkt.

Gebruik drie niveaus van monitoring

1. Basischeck: vraag `/up` op met een korte timeout.
2. Kritieke dependency-check: controleer alleen een dependency waarvan uitval de applicatie vrijwel onbruikbaar maakt, bijvoorbeeld de primaire database.
3. Functionele monitoring: controleer apart een representatieve publieke route, API-call of veilige synthetic flow.

Deze scheiding voorkomt false positives en onnodige fragiliteit. Een te oppervlakkige monitor blijft groen terwijl gebruikers fouten krijgen. Een te zware health check wordt zelf instabiel omdat iedere externe provider of optionele integratie de algemene status kan doen falen.

Een lichte databasecheck met `DiagnosingHealth`

Als vrijwel iedere relevante request de primaire database nodig heeft, is een kleine databasecheck verdedigbaar. Houd de query goedkoop, read-only en voorspelbaar. Een eenvoudige `select 1` controleert de verbinding zonder businessdata op te vragen.

<?php

namespace App\Providers;

use Illuminate\Foundation\Events\DiagnosingHealth;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Event;
use Illuminate\Support\ServiceProvider;

final class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Event::listen(DiagnosingHealth::class, static function (): void {
            DB::select('select 1');
        });
    }
}

Voeg niet automatisch checks toe voor elke tabel, externe provider of optionele feature. Health endpoints worden vaak frequent opgevraagd. Zware queries en netwerkcalls vergroten belasting, latency en de kans op een fout alarm.

Externe diensten horen meestal apart

Een betaalprovider, CRM, kaartendienst of e-mailprovider kan tijdelijk uitvallen zonder dat je hele website offline is. Monitor zulke afhankelijkheden apart wanneer ze bedrijfskritisch zijn. Laat een optionele API niet bepalen of de volledige applicatie gezond is.

• Geen volledige checkout uitvoeren vanuit `/up`.
• Geen testmail versturen bij iedere health request.
• Geen zware rapportquery als databaseprobe gebruiken.
• Geen persoonsgegevens, secrets, stack traces of providerdetails in de publieke health response tonen.

Laravel 13 en JSON health responses

Laravel 13 kan voor de ingebouwde health route JSON teruggeven wanneer de client daarom vraagt. Voor een externe monitor blijft de HTTP-status belangrijker dan de tekst van de response. Een eenvoudige smoke check kan er zo uitzien:

curl --fail --silent --show-error \
  --max-time 5 \
  --header 'Accept: application/json' \
  https://example.com/up

Shared hosting: houd het request-based

Op shared hosting is een HTTP health check handig omdat er geen permanente worker, daemon, Redis of Supervisor nodig is. Een externe monitor kan periodiek `/up` opvragen. Monitoring detecteert problemen, maar verandert de runtimebeperkingen van de hosting niet en mag kritieke flows niet afhankelijk maken van background processing.

Na deployment

Combineer de health route met minstens één niet-destructieve smoke check van een representatieve publieke pagina of API-route. Controleer daarnaast of er geen nieuwe kritieke exceptions in de logs verschijnen en zorg dat het rollbackpad bekend is vóór je het nodig hebt.

Samenvatting

Laravel's ingebouwde `/up` route is een goede, framework-native basis voor productie-monitoring. Gebruik `DiagnosingHealth` alleen voor echt kritieke dependencies, houd de response minimaal en monitor functionele gebruikersflows afzonderlijk. De beste health check probeert niet alles te testen, maar beantwoordt één duidelijke vraag betrouwbaar.