README

Health-Check Endpoint für Phoenix Monitor — Shopware 6 Integration.

Technischer Plugin-Name: RenekreuplPhoenixMonitor

Installation

composer require renekreupl/phoenix-monitor-shopware
bin/console plugin:refresh
bin/console plugin:install --activate RenekreuplPhoenixMonitor
bin/console cache:clear

Konfiguration

Token per CLI setzen:

bin/console system:config:set RenekreuplPhoenixMonitor.config.secretToken 'dein-geheimes-token'

Alternativ im Admin unter Erweiterungen → Meine Erweiterungen → Phoenix Monitor → Konfigurieren, oder per Umgebungsvariable (hat Vorrang, wenn gesetzt):

PHOENIX_MONITOR_TOKEN=dein-geheimes-token

Endpoint

GET /phoenix-monitor/status
X-Phoenix-Token: dein-geheimes-token

Der Pfad ist identisch zu den TYPO3- und Laravel-Paketen. Das Plugin registriert dafür einen eigenen Route-Scope (phoenix_monitor). Dadurch braucht der Endpoint weder eine Sales-Channel-Domain noch einen OAuth-Login und funktioniert auch bei unbekanntem Host. Die Authentifizierung läuft ausschließlich über den Header X-Phoenix-Token (Vergleich mit hash_equals).

Status	Bedeutung
200	Token korrekt, Payload wird ausgeliefert
401	Token fehlt oder ist falsch
503	Kein Token konfiguriert (`{"error":"not configured"}`)

Die Antwort wird mit Cache-Control: no-store ausgeliefert und landet weder im Shopware-HTTP-Cache noch in vorgeschalteten Caches.

Response

{
    "monitor_version": "1.1.0",
    "cms":             "shopware",
    "cms_version":     "6.7.15.1",
    "php_version":     "8.3.x",
    "checked_at":      "2026-10-28T03:09:05+01:00",
    "extensions": [
        {
            "key": "RenekreuplPhoenixMonitor",
            "title": "Phoenix Monitor",
            "version": "1.0.0",
            "state": "active",
            "type": "plugin",
            "composer_name": "renekreupl/phoenix-monitor-shopware",
            "upgrade_version": null
        }
    ],
    "updates_available": 0,
    "packages": [{ "name": "shopware/core", "version": "v6.7.15.1" }],
    "system_checks": [
        { "name": "LocalesReadiness", "category": "SYSTEM", "status": "OK", "healthy": true, "message": "All locales are OK", "context": "recurrent" },
        { "name": "SalesChannelsReadiness", "category": "FEATURE", "status": "OK", "healthy": true, "message": "All sales channels are OK", "context": "pre_rollout" }
    ],
    "system_checks_meta": {
        "checked_at": "2026-10-28T11:54:29+01:00",
        "contexts": ["recurrent", "pre_rollout"],
        "duration_ms": 320,
        "source": "scheduled",
        "stale": false
    },
    "scheduled_tasks": {
        "total": 28,
        "failed": 0,
        "overdue": 0,
        "last_run_at": "2026-10-28T03:00:00+01:00",
        "items": [
            {
                "name": "log_entry.cleanup",
                "status": "scheduled",
                "last_execution_time": "2026-10-28T03:00:00+01:00",
                "next_execution_time": "2026-10-29T03:00:00+01:00",
                "run_interval": 86400
            }
        ]
    },
    "last_scheduler_run": "2026-10-28 03:00:00",
    "queue": { "pending": 0, "oldest_message_at": null },
    "security_plugin": { "installed": true, "active": true, "version": "3.x" },
    "environment": { "app_env": "prod", "http_cache_enabled": true, "app_url": "https://shop.example" },
    "errors": []
}

Alle Zeitangaben sind in Europe/Berlin.

Datenquellen

extensions: Entities plugin und app. upgrade_version ist nur gesetzt, wenn Shopware selbst einen Store-Update-Check durchgeführt hat. Das Plugin fragt den Store nicht ab.
packages: alle Composer-Pakete (Composer\InstalledVersions).
system_checks: Ergebnis des letzten Laufs der Shopware-System-Checks, siehe unten.
scheduled_tasks: Entity scheduled_task. overdue heißt: Status scheduled/queued und next_execution_time liegt mehr als zwei Intervalle (mindestens eine Stunde) zurück. inactive/skipped zählen nicht als Fehler.
queue: ungelieferte Messages im Doctrine-Transport (messenger_messages, ohne die Queue failed). Bei Redis/AMQP oder fehlender Tabelle ist pending null und errors enthält einen Hinweis.
security_plugin: Plugin SwagPlatformSecurity.

Wirft ein Collector eine Exception, steht sie unter errors ({collector, message}). Die übrigen Daten werden trotzdem mit HTTP 200 ausgeliefert.

System-Checks

Im Web-Kontext lässt Shopware alle Core-Checks aus (SKIPPED). Deshalb führt ein Scheduled Task (phoenix_monitor.system_check) die Checks im Hintergrund aus und speichert das Ergebnis in system_config (Schlüssel RenekreuplPhoenixMonitor.systemCheckResult). Der Endpoint liefert nur dieses gespeicherte Ergebnis und führt keine Checks pro Request aus.

Der Task läuft in zwei Kontexten:

recurrent: läuft immer.
pre_rollout: die Readiness-Checks. Sie rendern interne Storefront-Seiten (kein externer HTTP-Call). Abschaltbar über „Readiness-Checks ausführen“ in der Plugin-Konfiguration (Default an).

Nicht ausgeführte Checks (im Kontext nicht erlaubt) erscheinen nicht in der Liste. Ein Check, der eine Exception wirft, steht mit status: FAILURE und healthy: false in der Liste, die übrigen laufen weiter. Hängt ein Check (Timeout), blockiert er den Task, da PHP keine Zeitbegrenzung pro Check bietet. Dann wird system_checks_meta.stale gesetzt.

Shopware	Checks
6.6	`SaleChannelsReadiness` (pre_rollout, so im Core geschrieben)
6.7	`LocalesReadiness` (recurrent), `AdministrationReadiness`, `SalesChannelsReadiness`, `ProductDetailReadiness`, `ProductListingReadiness` (pre_rollout)

Weitere Checks von Drittplugins werden automatisch erfasst, sobald sie sich beim Core registrieren (shopware.system_check).

`system_checks_meta`

Feld	Bedeutung
`source`	`scheduled`, oder `none`, solange noch kein Lauf gespeichert ist (kein Fehler)
`checked_at`	Zeitpunkt des Laufs (ISO 8601, Europe/Berlin), `null` bei `none`
`contexts`	ausgeführte Kontexte, z. B. `["recurrent", "pre_rollout"]`
`duration_ms`	Gesamtlaufzeit des Laufs
`stale`	`true`, wenn der Lauf älter als das Dreifache des Intervalls ist (Scheduler steht)

Intervall und manueller Lauf

Das Intervall steht in der Plugin-Konfiguration („Intervall der System-Checks“, Default 3600 s, Minimum 300 s) und wird beim Speichern auf den Scheduled Task übertragen. Setzen per CLI:

bin/console system:config:set RenekreuplPhoenixMonitor.config.systemCheckInterval 1800

Nach Installation oder Update des Plugins muss der Task registriert sein (bin/console scheduled-task:register, das passiert bei plugin:install/plugin:update automatisch). Er läuft über den normalen Shopware-Scheduler und Messenger-Worker (scheduled-task:run, messenger:consume).

Manuell auslösen und speichern, z. B. nach dem Rollout:

bin/console phoenix-monitor:system-check

Entwicklung

composer install
composer lint   # php-cs-fixer (Dry-Run)
composer stan   # PHPStan Level 8
composer test   # PHPUnit

Die Payload-Felder werden von Collectors geliefert (PayloadCollectorInterface, Service-Tag renekreupl_phoenix_monitor.collector).

Kompatibilität

PHP 8.2+
Shopware 6.6 / 6.7

renekreupl / phoenix-monitor-shopware

Package info

Security

Statistics