Verbrauch und Limits

Aktualisiert 7. Sept. 2026·3 Min. Lesezeit

Jeder Plan bringt Zahlen mit: wie viele Requests pro Monat, wie viele gleichzeitig, wie viele Simulationen. Auf dieser Seite geht es darum, wo du sie im Blick behältst und was passiert, wenn eine ausgeht.

Verbrauch auf einen Blick

Das Panel über der Simulationsliste fasst zusammen, was die Simulationen deiner Organisation ausgeliefert haben:

Die Verbrauchskarten über der Simulationsliste
  • Requests: bediente Aufrufe im gewählten Zeitraum, neben dem Monatskontingent.
  • Datentransfer: gesendete Antwort-Bytes, gegen das Kontingent des Plans, wo eines gilt.
  • Rate Limited: Requests, die die Plattform mit einem 429 beantwortet hat, statt sie zu bedienen. Eine Zahl hier heißt, Aufrufer sind an ein Limit gestoßen.
  • Plattformfehler: Ausfälle auf unserer Seite, nicht auf deiner.
  • Deployments und Routen-Updates: wie oft die Simulationen deployt und umkonfiguriert wurden.

Der Zeitraum wechselt zwischen den letzten 24 Stunden, 7, 30 und 90 Tagen; längere Zeiträume gehören zu Plänen, die sie enthalten. Jede Simulationszeile in der Liste darunter trägt ihre eigenen Request- und Fehlerzahlen für denselben Zeitraum.

Die Anzeigen

Simulationen und Refs zählen gegen den Plan, sobald sie existieren, deployt oder nicht:

Eine von einer Simulation verwendet, daneben die Refs-Anzeige

Eine volle Anzeige heißt: Das nächste Anlegen wird abgelehnt, bis etwas gelöscht wird oder der Plan wächst.

Was jedes Limit tut

  • Monatliche Requests gelten für alle Simulationen zusammen und setzen sich am Ersten des Monats zurück. Jenseits des Kontingents werden Requests mit 429 beantwortet, bis der Zähler zurücksetzt oder ein Top-up nachlegt.
  • Durchsatz begrenzt, wie viele Requests pro Sekunde die Simulationen im selben Moment bedienen. Kurze Spitzen darüber werden mit 429 gedrosselt, und genau das zählt die Karte Rate Limited.
  • Datentransfer ist der Antwortverkehr, den deine Simulationen nach draußen senden, gemessen am Kontingent des Plans.
  • Speicher und Timeout formen jeden Request zur Laufzeit: Eine schwere Spec braucht Speicher, ein langsamer Upstream zehrt am Timeout. Beide stehen auf dem Bereitstellungs-Tab der Simulation.

Siehe OpenAPI-Spec hochladen und aktualisieren dafür, wann eine Spec ihrem Speicher entwächst, und Service-Einstellungen dafür, wie der Upstream-Timeout unter dem Request-Timeout bleibt.

Luft nachkaufen

Aufstocken, auf der Requests-Karte oder unter Abrechnung, kauft ein einmaliges Top-up oben auf das Monatskontingent; das ist die schnelle Lösung für einen Monat, der voller wurde als geplant. Alles andere, mehr Durchsatz, mehr Simulationen, mehr Speicher, längerer Verlauf, kommt mit einem Planwechsel.

Die Zahlen hinter jedem Limit sind je Plan; die Preisseite stellt sie nebeneinander.

War diese Seite hilfreich?