Logs, Checks und Datenbank

Kommt später: gooddeploy logs und gooddeploy checks report liefert die Plattform; Postgres (gooddeploy db …) noch nicht. Bis dahin endet db mit „noch nicht verfügbar“ (Exit-Code 6). Auf einer Plattform ohne gespeicherte Checks endet auch checks report so.

Logs ansehen: logs

gooddeploy logs                       # Live-Version
gooddeploy logs --env preview         # Previews
gooddeploy logs k7m2q9xa              # ein bestimmtes Deployment
gooddeploy logs k7m2q9xa --build      # sein Build-Log
gooddeploy logs --since 10m --follow  # letzte 10 Minuten, dann live weiter

Läuft deine Anwendung auf mehreren Servern, steht vor jeder Zeile der Server in eckigen Klammern, z. B. [node-1] GET / 200. Mit --follow (kurz -f) zeigt gooddeploy neue Zeilen, bis du mit Strg+C abbrichst; das endet normal mit Exit-Code 0.

Option	Wirkung
`--follow`, `-f`	neue Zeilen nachliefern, bis Strg+C
`--since <dauer>`	nur Zeilen aus diesem Zeitraum, z. B. `30s`, `10m`, `2h`
`--build`	Build-Log statt Laufzeit-Logs (nur mit einer Deployment-ID)
`--env production\|preview`	ohne ID: welche Umgebung (Standard `production`)

Mit --json kommt je Zeile ein JSON-Objekt mit line, node, stream und at. Geheimnisse aus deinen Umgebungsvariablen erscheinen in Logs als [maskiert].

Eigene Checks melden: checks report

Neben den eingebauten Prüfungen (Build, Health, Smoke) kann deine CI eigene Checks an ein Deployment melden, z. B. das Ergebnis von E2E-Tests:

gooddeploy checks report k7m2q9xa e2e pending
npm run test:e2e        # Tests gegen die Preview
gooddeploy checks report k7m2q9xa e2e success --url "$CI_JOB_URL" --description "42 Tests grün"

Der Zustand ist pending, success oder failure; eine neue Meldung ersetzt die vorige. Die eingebauten Namen build, health, smoke und tests setzt nur die Plattform; eine Meldung unter diesen Namen lehnt sie mit VALIDATION_FAILED ab. Check-Namen bestehen aus Kleinbuchstaben, Ziffern, -, _ und . (z. B. e2e). --url muss eine http(s)-Adresse sein, --description höchstens 500 Zeichen lang. Dafür braucht der Zugangscode das Recht deploy.

Pflicht-Checks legst du in gooddeploy.json unter checks.required fest (z. B. ["e2e"]). Fehlt einer oder ist er nicht grün, lehnt promote ab (REQUIRED_CHECK_MISSING bzw. REQUIRED_CHECK_FAILED). Das gilt auf Plattformen, die Checks speichern; auf allen anderen kommt es später.

Datenbank: db info und db dump

gooddeploy db info

Postgres kunde-website
  UMGEBUNG  DATENBANK              GRÖSSE   VERBINDUNGEN
  Live      kunde_website_prod     12,0 MB  3
  Previews  kunde_website_preview  300 KB   0

Live und Previews haben je eine eigene Datenbank. gooddeploy db ohne Unterbefehl macht dasselbe wie db info.

gooddeploy db dump                       # kunde-website-prod-2026-10-18.dump
gooddeploy db dump -o vor-update.dump    # eigener Dateiname

db dump lädt eine Sicherung der Live-Datenbank im Format von pg_dump -Fc herunter. Die Datei ist nur für dich lesbar; eine vorhandene Datei überschreibt gooddeploy nie, und ein abgebrochener Download hinterlässt keine halbe Datei. Einspielen kannst du sie z. B. in eine lokale Datenbank:

pg_restore --no-owner -d meine_lokale_db kunde-website-prod-2026-10-18.dump

db info braucht read, db dump braucht read:sensitive (siehe Rechte).