Postman API-Überwachung, die Ihre Sammlungen in 24/7 Produktionsmonitore verwandelt

Ja. Importieren Sie Postman Collection v2.0 und v2.1 JSON-Dateien direkt. Ordner, Anfragen, Umgebungsvariablen, Pre-Request-Skripte und Test-Assertions bleiben beim Import erhalten.

Postman Monitors führt Ihre Collection aus Postmans Cloud-Regionen nach Zeitplan aus. Dotcom-Monitor führt dieselbe Collection von über 30 eigenen globalen Standorten aus, fügt Private Agents für Prüfungen hinter Firewalls hinzu, bietet native PagerDuty/Slack/Teams-Routing und behandelt es als vollständiges synthetisches Monitoring mit eigenem 99,99 % SLA – nicht als sequentielle Testausführung.

Ja. Statische und dynamische Umgebungsvariablen (inklusive Postman-eigener wie {{$randomUUID}}) werden direkt importiert, zusammen mit Pre-Request-Skripten und Test-Assertions, die in Postmans JavaScript-Dialekt verfasst sind.

Ja. Wähle aus über 30 globalen Überwachungsstandorten und führe die Collection parallel von jedem aus aus. Erfasse das regionale CDN-Problem oder DNS-Propagation-Lücke, die bei der Überwachung von nur einem Standort übersehen wird.

Ja. So oft wie jede Minute pro Collection. Für kritische Pfade (Login, Zahlung, Checkout) empfehlen wir 1-Minuten-Intervalle; weniger kritische Collections nutzen typischerweise 5- oder 15-Minuten-Intervalle.

Ja. Importiere Umgebungen zusammen mit Collections — wähle, welche Umgebung pro Monitor verwendet werden soll (Dev/Staging/Prod), und importiere erneut, wenn sich dein Postman-Arbeitsbereich weiterentwickelt.

Ja. Löse Monitorläufe von GitHub Actions, Jenkins, Azure DevOps oder jedem Tool aus, das HTTP-Aufrufe tätigen kann. Steuere die Bereitstellung anhand von Assertionsergebnissen, Latenz oder Verfügbarkeitsgrenzen.

Ja. Setze Private Agents innerhalb deiner VPC oder deines Rechenzentrums ein — dieselbe Collection läuft gegen interne Endpunkte ohne eingehende Firewall-Regel.

Gleiche Geschichte — importiere Insomnia v4 Exporte direkt. Siehe Insomnia API Monitoring →

Postman JavaScript-Skripte, die die pm.environment, pm.variables und pm.collectionVariables APIs verwenden, werden unterstützt. Dynamische Variablen ({{$randomInt}}, {{$randomUUID}}, usw.) werden zur Anfragezeit ausgeführt. Skripte, die auf Postman-spezifische APIs angewiesen sind, die außerhalb von Postman nicht verfügbar sind, werden beim Import markiert.

Ja. Dynamische Umgebungsvariablen werden bei jedem Monitorlauf aufgelöst, so dass Werte wie Zeitstempel, zufällige UUIDs und eindeutige IDs pro Prüfung neu generiert werden.

Ja. Importierte Collections befinden sich auf Kontoebene und können über rollenbasierte Zugriffssteuerung mit Teammitgliedern geteilt werden. Aktualisierungen der importierten Collection wirken sich auf alle Monitore aus, die darauf verweisen.

Du kannst Newman lokal in CI als Teil von Pre-Deploy-Tests ausführen UND dieselbe Collection bei Dotcom-Monitor für kontinuierliche Post-Deploy-Überwachung registrieren. Beide verwenden dieselbe Collection-JSON.