Typische Deployment-Fehler und Strategie für deren Fehlersuche

1. Anatomie des Deployments: wo es überhaupt brechen kann

Es ist hilfreich, die gesamte Kette zuerst zu betrachten. Das Deployment der ChatGPT App in Ihrer Architektur lässt sich gedanklich in folgende Pipeline entfalten:

flowchart TD
  A[Ihr Laptop
git commit] --> B[Git-Repository
GitHub/GitLab]
  B --> C[Vercel Build
npm run build]
  C --> D[Vercel Deploy
Preview/Prod]
  D --> E[HTTP endpoint
/mcp, /api/...]
  E --> F[ChatGPT / Dev Mode
tool calls, widgets]

Ein Fehler kann in jedem dieser Schritte auftreten, aber die Symptome sehen in ChatGPT ähnlich aus: "Error talking to app", "Network error" oder schlichtes Schweigen. Ihre Aufgabe – nicht ins Blaue zu schießen, sondern zunächst zu verstehen: Ist es beim Build, zur Laufzeit, oder schaut ChatGPT auf die falsche Adresse?

Praktisch ist es, die Probleme in drei große Kategorien zu unterteilen:

• Build‑Fehler: Vercel konnte das Projekt überhaupt nicht bauen. Die Produktion wurde nicht aktualisiert – das ist „gut“, aber Sie sehen einen roten Build.
• Runtime‑Fehler: Der Build ist durch, aber bei Anfragen kommen 500/502, Timeouts oder seltsames Verhalten.
• Config Drift (Konfigurations‑Drift): lokal ist alles ok, auf Vercel laut Logs ebenfalls, aber ChatGPT greift auf eine alte URL zu, arbeitet mit einem alten Manifest oder mit leeren Env‑Variablen.

Wir gehen diese drei Schichten durch und entwickeln parallel eine allgemeine Debugging‑Strategie.

2. Build‑Fehler: wenn das Projekt nicht gebaut wird

Das ist der erste Problemtyp aus der Einleitung – Build‑Fehler: Das Projekt wird überhaupt nicht gebaut, weil Vercel Ihr Next.js‑Projekt nicht erfolgreich bauen kann.

Node und Next.js: andere Umgebung, andere Anforderungen

Lokal können Sie (leider) mit einer veralteten Node‑Version leben, während Vercel versucht, Ihr Next.js‑16‑Projekt mit einer unterstützten Node‑Version (mindestens 18.18.0) zu bauen. Wenn in package.json explizit eine inkompatible Version angegeben ist, kann der Build in Prod scheitern, obwohl Ihr Dev‑Server lief.

Ein einfacher Schutz besteht darin, in package.json explizit "engines" zu setzen:

{
  "engines": {
    "node": ">=18.18.0"
  }
}

Dann sehen Sie sowohl lokal als auch im CI/auf Vercel frühzeitig, dass Ihre Node‑Version zu alt ist.

„Bei mir läuft’s!“ und vergessene Abhängigkeiten

Der Klassiker: Sie haben eine Bibliothek via npm install some-lib installiert, aber die aktualisierte package-lock.json nicht committet oder Sie haben einen Teil der Abhängigkeiten global installiert. Auf Vercel wird die Anwendung „from scratch“ gebaut, es führt npm install ehrlich anhand des Manifests aus, doch Ihre Lieblings‑some-lib ist dort nicht vorhanden – Ergebnis: Build‑Fehler.

Hier hilft strikte Disziplin:

• alle neuen Abhängigkeiten werden hinzugefügt und sofort committet;
• vor dem Push in main/production führen Sie npm run build lokal aus. Wenn der lokale Build fällt, wird es auf Vercel nur schlimmer.

Case‑sensitive Dateisystem

Lokal arbeiten viele auf macOS oder Windows, wo das Dateisystem standardmäßig nicht zwischen Groß‑/Kleinschreibung unterscheidet. Auf Vercel läuft der Build in einer Linux‑Umgebung, dort sind Widget.tsx und widget.tsx unterschiedliche Dateien.

Typischer Bug:

// Import im Code
import { AppWidget } from "@/components/Widget";

// Aber im Repository liegt die Datei components/widget.tsx

Auf Ihrem Rechner funktioniert alles, auf Vercel gibt es einen Modulfehler „Cannot find module '@/components/Widget'“. Das löst man durch Ordnung in den Namen und sorgfältigen Umgang mit Groß‑/Kleinschreibung.

Env‑Variablen zur Build‑Zeit

Eine weitere Überraschungsquelle ist die Verwendung von process.env.* im Code, der zur Build‑Zeit ausgeführt wird (z. B. in next.config.mjs oder in Modulen, die beim Build importiert werden). Wenn Sie lokal .env.local eingebunden haben, auf Vercel diese Variablen für die Build‑Umgebung aber fehlen, stürzt der Build entweder ab oder – unangenehmer – läuft mit undefined durch und „backt“ ungültige Werte in das Bundle.

Für die ChatGPT App ist das besonders kritisch, wenn Sie z. B. die baseURL für den MCP‑Endpunkt oder URLs externer APIs bereits zur Build‑Zeit formen.

Gute Praxis ist es, kritische Env‑Variablen bereits vor dem App‑Start explizit zu validieren (darüber sprechen wir in einem separaten Abschnitt), damit der Build laut und vorhersehbar fehlschlägt.

3. Runtime‑Fehler: wenn alles gebaut ist, aber nicht funktioniert

Nun zum zweiten Layer aus der Einleitung – Runtime‑Fehlern: Der Build ist durch, aber zur Laufzeit bricht etwas.

Der Build ist durch, Vercel zeigt freudig einen grünen Deploy, Sie schalten die ChatGPT App auf die Prod‑URL – und bekommen im Chat "Error talking to app". Die Probleme sind also auf die Ausführungsebene übergegangen.

Null‑ oder leere Env‑Variablen

Am häufigsten beginnt ein Prod‑Incident in der Welt der ChatGPT App mit dem Wort undefined. Lokal haben Sie eine saubere .env.local mit OPENAI_API_KEY, MCP_BASE_URL und mehr, auf Vercel wurden diese Variablen aber vergessen oder falsch benannt.

Beispielsweise lesen Sie:

const apiKey = process.env.OPENAI_API_KEY;

und auf Vercel wurde OPENAI_APIKEY oder OPENAI_API_KEY_PROD angelegt. Das Ergebnis: Beim ersten Aufruf des MCP‑Tools stürzt Ihr Route‑Handler mit einem Authentifizierungsfehler ab.

Viel angenehmer ist es, wenn die Anwendung sofort und verständlich fehlschlägt. Ein gutes Pattern ist ein separates Modul in Ihrem Next.js‑Projekt, das Env‑Variablen beim Import validiert:

// app/lib/env.ts
const required = ["OPENAI_API_KEY", "MCP_BASE_URL"] as const;

type RequiredKey = (typeof required)[number];

function getEnv(key: RequiredKey): string {
  const value = process.env[key];
  if (!value) {
    throw new Error(`Missing required env var: ${key}`);
  }
  return value;
}

export const env = {
  OPENAI_API_KEY: getEnv("OPENAI_API_KEY"),
  MCP_BASE_URL: getEnv("MCP_BASE_URL"),
};

Jetzt, wenn Sie die Variablen auf Vercel vergessen haben, fällt Next.js bereits beim ersten Import von env, und in den Logs steht eine verständliche Meldung "Missing required env var: ...".

Wichtig: Auf Vercel werden Änderungen an Env‑Variablen nicht automatisch übernommen. Nach dem Anpassen der Werte müssen Sie einen neuen Deploy durchführen (redeploy), sonst läuft der Runtime weiterhin mit den alten Werten.

Fehler in Route‑Handlern und am MCP‑Endpunkt

Im offiziellen ChatGPT‑App‑Template ist der MCP‑Server meist als app/mcp/route.ts implementiert. Darin parsen Sie die JSON‑RPC‑Anfrage, routen sie zum Tool und geben die Antwort zurück. Wenn irgendwo in der Kette ein throw ohne Handling passiert – erhält der Nutzer in ChatGPT eine 500.

Sie sollten die oberste Ebene des MCP‑Handlers immer in try/catch einwickeln, den Fehler loggen und eine strukturierte Antwort zurückgeben:

// app/mcp/route.ts
import { NextRequest, NextResponse } from "next/server";

export const dynamic = "force-dynamic";
export const maxDuration = 30; // Sekunden

export async function POST(req: NextRequest) {
  try {
    const body = await req.json();
    // hier Verarbeitung der MCP-Anfrage
    const result = await handleMcpRequest(body);
    return NextResponse.json(result);
  } catch (error) {
    console.error("MCP route error", error);
    return NextResponse.json(
      { error: "Internal MCP error" },
      { status: 500 }
    );
  }
}

Ein paar Punkte:

• dynamic = "force-dynamic" hilft, unerwartete statische Generierung und Caching für MCP‑Routen in Next.js 16 zu vermeiden.
• maxDuration = 30 sagt Vercel explizit, dass der Route‑Handler bis zu 30 Sekunden laufen darf, was bei langen LLM‑Anfragen wichtig ist.

Timeouts und „Network error“ in ChatGPT

Vercel begrenzt die Laufzeit von Serverless‑Funktionen: in den kostenlosen Tarifen sind das meist etwa 10 Sekunden, in den kostenpflichtigen kann es mehr sein (bis zu mehreren Minuten). Wenn Ihr MCP‑Tool eine lange Anfrage an eine Datenbank oder ein externes API stellt, kann es nicht rechtzeitig antworten, und ChatGPT erhält "Network error" oder einen abgebrochenen Stream.

Wenn Sie Streaming (SSE) für Teil‑Ergebnisse verwenden, ist es besonders wichtig, die ersten Bytes der Antwort vor Ablauf des Timeouts zu senden. Dann darf die Übertragung selbst länger dauern, ohne dass die Plattform die Funktion als „hängend“ wertet.

Kleiner Trick: Messen Sie die Laufzeit der Tool‑Aufrufe und loggen Sie sie zusammen mit dem Tool‑Namen. Dann ist in den Logs sichtbar, dass search_flights beispielsweise stabil 12 Sekunden braucht und knapp außerhalb des Limits liegt.

export async function safeToolCall<TInput, TOutput>(
  name: string,
  handler: (input: TInput) => Promise<TOutput>,
  input: TInput
): Promise<TOutput> {
  const started = Date.now();
  try {
    const result = await handler(input);
    console.log("[tool] ok", name, { ms: Date.now() - started });
    return result;
  } catch (error) {
    console.error("[tool] fail", name, {
      ms: Date.now() - started,
      error,
    });
    throw error;
  }
}

Anschließend rufen Sie statt handler(args) safeToolCall("search_flights", handler, args) auf.

Netzwerk und externe Dienste

Manchmal liegt es schlicht an https:// statt http:// oder einer veralteten baseURL. Besonders, wenn Sie zuerst lokal mit einer URL getestet haben, in Prod jedoch eine andere Domain oder ein anderer Port genutzt wird.

Es ist sinnvoll, Basis‑URLs in die Konfiguration (abhängig von der Umgebung) auszulagern und nicht direkt in das Tool zu codieren. Dann ändern Sie beim Wechsel der Umgebung eine Env‑Variable statt sich zu erinnern, an welchen fünf Stellen im Code http://localhost:3001 stand.

4. Konfiguration und Umgebungs‑Drift

Und schließlich der dritte Typ aus unserem Schema – Konfigurations‑Drift zwischen Umgebungen.

Selbst wenn der Build durch ist und die Runtime laut Logs gesund ist, kann sich ChatGPT so verhalten, „als ob eine andere Version der Anwendung läuft“. Das ist ein Fall, in dem das Problem weniger im Code liegt, sondern in der Konfiguration und der Konsistenz der Umgebungen.

Dev Mode versus Produktion

Im Dev Mode schaut ChatGPT auf die Connector‑URL, die Sie manuell angegeben haben: meist eine Tunnel‑URL (https://myapp-dev.ngrok-free.app/mcp oder etwas Ähnliches) oder eine Staging‑URL auf Vercel. In der Produktion (über den Store oder die Organisationseinstellungen) sollte die App auf einen stabilen Prod‑Endpunkt zeigen, zum Beispiel https://myapp.vercel.app/mcp.

Der Fehler, den fast jeder macht: Sie haben auf Vercel deployed, aber in den Einstellungen der ChatGPT App ist noch die alte Tunnel‑URL eingetragen. Der lokale Server ist aus, der Tunnel längst tot, und ChatGPT klopft dort an und bekommt 502. In der Oberfläche sieht das wie "Error talking to app" aus, und man fängt an, MCP‑Code zu reparieren, der gar nicht ausgeführt wird.

Heilung durch Disziplin: Nach jeder Änderung der Umgebung (Tunnel → Staging, Staging → Prod) prüfen Sie, welche URL im Dev Mode und in der Prod‑Konfiguration der App hinterlegt ist.

Altes Manifest und ChatGPT‑Cache

ChatGPT cacht Informationen über Ihre App: Liste der Tools, ihre Beschreibungen, Metadaten. Daher ist die Situation „Ich habe das Tool‑Schema geändert, aber das Modell geht noch vom alten Parameternamen aus“ real.

Bei größeren Änderungen an Tools ist es hilfreich:

• sicherzustellen, dass Sie wirklich die neue Version deployed haben (Commit‑Hash in den Logs ansehen, ihn im Startup‑Log ausgeben);
• die App im Dev Mode neu zu erstellen oder neu zu verbinden, um die Plattform zum erneuten Einlesen des Manifests zu zwingen;
• während des Debuggings über den MCP Inspector zu arbeiten, wo Sie die aktuelle Liste der Tools und Schemata sicher sehen.

Env‑Konfiguration: Dev/Staging/Prod

Wir haben bereits darüber gesprochen, wie Env‑Variablen Build und Runtime zum Absturz bringen können. Hier der Blick von oben auf Dev/Staging/Prod und die Konsistenz der Werte zwischen ihnen.

Häufiger Schmerz: Ihre .env.local ist ideal, die Vercel‑Umgebungen jedoch ein Zoo. Ergebnis:

• lokal haben Sie einen API‑Key und eine URL eines externen Dienstes;
• auf Staging sind es ganz andere Werte;
• auf Prod sind die Hälfte der Variablen nicht gesetzt.

Sehr hilfreich ist eine einfache Textdatei docs/env.md im Repository, in der Sie auflisten: welche Variablen benötigt werden, in welchen Umgebungen sie Pflicht sind, welche Beispielwerte es gibt. Das wirkt bürokratisch, spart im Incident jedoch Stunden.

5. Wie Fehler auf der ChatGPT‑Seite aussehen

Schauen wir nun auf die Situation aus Sicht des ChatGPT‑Nutzers. Er sieht nur die Oberfläche und weiß nichts über Vercel, Node und MCP. Und Sie wissen leider zunächst auch nicht, was genau kaputt ist.

Typische Symptome in ChatGPT:

• die Meldung "Error talking to [App Name]" direkt nach dem Versuch der Nutzung;
• ein endloser Spinner ohne sichtbare Fehlermeldung;
• roter Text "I encountered an error while running the tool";
• das Widget erscheint nicht oder erscheint leer.

Jedes dieser Symptome entspricht in der Regel einer bestimmten Ebene des Defekts:

• wenn die App überhaupt nicht erreichbar ist (falsche URL, Tunnel down, SSL‑Fehler), kann ChatGPT Ihren MCP‑Endpunkt nicht erreichen – prüfen Sie die Erreichbarkeit der Domain im Browser und die Vercel‑Logs mit Codes 4xx/5xx;
• wenn der MCP mit gültigem JSON‑RPC und einem Feld error antwortet, schreibt ChatGPT ehrlich, dass das Tool einen Fehler zurückgegeben hat – das ist dann eine Frage der Business‑Logik oder der Argument‑Validierung;
• wenn der MCP erfolgreich antwortet, aber das HTML des Widgets kaputt ist oder ein JS‑Fehler auftritt, sieht man in der Widget‑Konsole (DevTools → iframe des Widgets), was genau gestürzt ist.

Daher eine gute Gewohnheit: Sobald Sie seltsames Verhalten im Chat sehen, notieren Sie sofort den Zeitstempel (minutengenau) und gehen in die Vercel‑Logs, um Anfragen zu diesem Zeitpunkt zu suchen.

6. Debugging‑Strategie: nicht in Panik geraten, sondern handeln

Wir bauen aus dem Gesagten nun ein kleines „Playbook“ – einen Handlungsplan, wenn etwas schiefgeht. Ziel ist es, das im Kreis rennen durch einen ruhigen Algorithmus zu ersetzen.

Schritt 1: Problemtyp bestimmen

Wenn der Build auf Vercel rot ist – freuen wir uns: der Fehler wurde vor der Produktion abgefangen. Öffnen Sie die Build‑Logs, suchen Sie den ersten echten Fehler (und nicht 200 Zeilen Warnungen) und reproduzieren Sie ihn lokal mit npm run build.

Wenn der Build grün ist und ChatGPT sich beschwert – geht es um Runtime oder Konfiguration. Prüfen Sie:

• ob die Prod‑URL Ihrer App im Browser erreichbar ist (gibt https://myapp.vercel.app/mcp überhaupt etwas zurück);
• ob der MCP‑Endpunkt 200/500 zurückgibt oder überhaupt nicht auflöst;
• ob die URL in den App‑Einstellungen mit der gerade geprüften übereinstimmt.

Schritt 2: Logs lesen, nicht Gedanken

Der nächste Halt sind die Vercel‑Logs: Server‑Logs für den passenden Deploy und die passende Umgebung (Preview/Production).

Gesucht sind:

• Fehler Error: Missing required env var ... – dann liegt das Problem in der Konfiguration;
• Stack Traces aus dem MCP‑Handler – dann stürzt die Business‑Logik oder das Parsen der Eingaben ab;
• Meldungen über Timeouts oder Überschreitung der Funktionsdauer.

Parallel dazu den MCP Inspector nicht vergessen. Wenn Sie sich mit demselben MCP‑Endpunkt über den Inspector verbinden und Tools manuell ausführen, wird schnell klar, ob das Problem im MCP selbst oder in der Kette ChatGPT ↔ MCP liegt.

Schritt 3: schneller Rollback oder Hotfix?

Wenn Sie sehen, dass der Prod‑Deploy klar defekt ist (z. B. der MCP‑Route wirft bei jeder Anfrage denselben Fehler), und der vorige Deploy gesund war, ist der richtige Schritt: zurückrollen. Vercel erlaubt das schnelle Umschalten auf den letzten erfolgreichen Deploy ohne Neu‑Build – im Grunde ein Wechsel der aktiven Version.

Das ist besser, als die Produktion „on the fly“ zu reparieren, besonders wenn die Ursache des Incidents noch unklar ist.

Sobald die Lage stabilisiert ist, analysieren Sie die Ursache in Ruhe, schreiben Tests, fixen den Code und releasen erst danach die nächste Version.

Schritt 4: Erkenntnisse in der Dokumentation festhalten

Jeder ernsthafte Incident ist ein Anlass, das interne README zu aktualisieren:

• eine zwingende Env‑Variable hinzufügen, ohne die alles abstürzt;
• festhalten, welcher konkrete Fall zum Fehler geführt hat (z. B. „Import mit falscher Groß‑/Kleinschreibung von Dateinamen“);
• einen kurzen Handlungsalgorithmus beschreiben, der beim schnellen Fix geholfen hat.

Das wirkt langweilig, aber in ein paar Monaten werden Sie sich selbst dafür danken.

7. Kleine praktische Kniffe im Code

Nehmen wir nun ein paar Schritte aus unserem Playbook und verankern sie mit kleinen Code‑Kniffen in unserer Lern‑Anwendung (ChatGPT App).

Einheitliches Konfigurationsmodul

Wir hatten bereits einen einfachen Validator für Env‑Variablen. Man kann ihn erweitern, um Umgebungen zu unterscheiden:

// app/lib/config.ts
type NodeEnv = "development" | "test" | "production";

const nodeEnv = (process.env.NODE_ENV || "development") as NodeEnv;

const requiredBase = ["OPENAI_API_KEY"] as const;
const requiredProd = ["MCP_BASE_URL"] as const;

function ensure(keys: readonly string[]) {
  for (const key of keys) {
    if (!process.env[key]) {
      throw new Error(`Missing env var ${key} for NODE_ENV=${nodeEnv}`);
    }
  }
}

ensure(requiredBase);
if (nodeEnv === "production") {
  ensure(requiredProd);
}

export const config = {
  nodeEnv,
  openaiApiKey: process.env.OPENAI_API_KEY!,
  mcpBaseUrl: process.env.MCP_BASE_URL ?? "http://localhost:3000/mcp",
};

Ein solches Modul hebt sofort hervor, wenn Prod ohne benötigte Variable startet.

Logging eingehender MCP‑Anfragen

Einfache, aber sehr nützliche Umrahmung für den MCP‑Handler:

// app/lib/mcp-logger.ts
export function logMcpRequest(body: unknown) {
  console.log("[mcp] request", {
    time: new Date().toISOString(),
    // keine sensiblen Daten loggen
    keys: typeof body === "object" && body !== null
      ? Object.keys(body as Record<string, unknown>)
      : typeof body,
  });
}

Und verwenden wir in app/mcp/route.ts:

import { logMcpRequest } from "@/app/lib/mcp-logger";

export async function POST(req: NextRequest) {
  try {
    const body = await req.json();
    logMcpRequest(body);
    const result = await handleMcpRequest(body);
    return NextResponse.json(result);
  } catch (error) {
    console.error("MCP route error", error);
    return NextResponse.json({ error: "Internal error" }, { status: 500 });
  }
}

In den Logs sehen Sie, was von ChatGPT überhaupt ankommt: zumindest anhand der Schlüssel ("jsonrpc", "method", "params"), und Sie verstehen leichter, welcher genaue Aufruf abstürzt.

Einfacher Healthcheck für den MCP‑Endpunkt

Manchmal ist ein kleiner Route‑Handler vom Typ „Healthcheck“ für den MCP‑Server nützlich, den ChatGPT nicht direkt aufruft, den Sie aber schnell im Browser öffnen können, um zu sehen, ob der Server lebt und seine Env‑Variablen sieht:

// app/api/health/route.ts
import { NextResponse } from "next/server";
import { config } from "@/app/lib/config";

export async function GET() {
  return NextResponse.json({
    status: "ok",
    env: config.nodeEnv,
    hasOpenAiKey: !!config.openaiApiKey,
  });
}

Wenn https://myapp.vercel.app/api/health mit status: "ok" antwortet, ist wenigstens die Basis‑Pipeline bis zu Ihrem Node‑Code lebendig.

8. Typische Fehler beim Deployment und Debugging

Fehler Nr. 1: Deployment ohne lokales npm run build.
Wenn ein Entwickler den Build nie lokal ausführt, erfährt er von einer inkompatiblen Node‑Version, einem Pfadproblem oder einem TS‑Fehler erst auf Vercel. Das verlängert den Zyklus „kaputt → gefixt“, weil jedes Experiment ein neuer Deploy ist. Die Gewohnheit, npm run build vor dem Push in main laufen zu lassen, spart viel Zeit (siehe auch Abschnitt 2 und Schritt 6.1 zum lokalen npm run build).

Fehler Nr. 2: Secrets existieren nur in .env.local.
Das Projekt läuft perfekt auf der Maschine des Autors, fällt in Prod aber um, weil process.env.OPENAI_API_KEY === undefined. Der banale Grund: Env‑Variablen wurden in den Vercel‑Einstellungen vergessen (oder sogar anders benannt). Besonders oft übersieht man die Trennung Development/Preview/Production und wundert sich, dass Staging und Prod sich unterschiedlich verhalten (mehr dazu in den Abschnitten 3.1, 4.3 und 7.1).

Fehler Nr. 3: Verwendung von NEXT_PUBLIC_* für Secrets.
In Next.js landen alle Variablen mit dem Präfix NEXT_PUBLIC_ im Browser‑Bundle. Wenn Sie aus Versehen den API‑Key NEXT_PUBLIC_OPENAI_API_KEY nennen, wandert er zum Nutzer in den Browser und kann aus den DevTools gezogen werden. Das darf man nicht tun. Öffentlich sollten nur sichere Werte sein (z. B. IDs für Feature‑Flags, aber keine Tokens).

Fehler Nr. 4: Vercel‑Logs ignorieren und versuchen, „über ChatGPT zu reparieren“.
Man sieht im Chat "Error talking to app" und ändert stundenlang Prompts, Tool‑Beschreibungen, dreht etwas im Dev Mode, schaut aber kein einziges Mal in die Serverless‑Logs. Dort steht oft ein klarer Fehler: "Missing env var", "Cannot find module" oder der Stack Trace eines konkreten Tools. Ein guter Engineer schaut zuerst in die Logs und diskutiert erst danach mit dem Modell.

Fehler Nr. 5: Verwechslung von Dev Mode und Production‑App.
Nach dem ersten erfolgreichen Deploy auf Vercel vergisst man leicht, dass der Dev Mode immer noch auf den alten Tunnel oder eine Preview‑URL zeigen kann. Sie glauben, die Produktionsversion zu testen, sprechen aber in Wirklichkeit mit einem lokalen Branch, der längst gelöscht werden sollte. Oder umgekehrt: Sie denken, Sie testen Roh‑Änderungen, aber ChatGPT klopft am Live‑Endpunkt an. Prüfen Sie regelmäßig, welche URL in den App‑Einstellungen und im Dev Mode hinterlegt ist (siehe auch Abschnitt 4.1 zu Dev Mode und Produktion).

Fehler Nr. 6: Erwartung, dass eine Änderung einer Env‑Variablen auf Vercel „on the fly“ greift.
Manche ändern Variablenwerte im Vercel‑Panel und rennen sofort zu ChatGPT, um das Ergebnis zu prüfen. Aber der Runtime verwendet noch die alten Werte, weil kein Redeploy durchgeführt wurde. Jede Änderung von Env‑Variablen erfordert einen neuen Deploy, sonst sieht die Funktion das Update nicht (Details – Abschnitt 3.1).

Fehler Nr. 7: Keine einfache Rollback‑Strategie.
Im Incident ist die Versuchung groß, „schnell einen Fix“ direkt in main zu pushen. Das produziert jedoch einen weiteren potenziell defekten Deploy, während Nutzer leiden. Viel ruhiger ist die Gewohnheit: Bei ernsten Fehlern sofort auf den letzten erfolgreichen Deploy zurückrollen, das Problem in einem separaten Branch fixen und erst danach die neue Version ausliefern. Vercel bietet dafür eine bequeme Oberfläche – es wäre schade, sie nicht zu nutzen.