Azure

Der nächtliche Import läuft seit Tagen nicht, und keiner merkt es? So überwachen Sie geplante Jobs

Bestellimport, Lagerabgleich und Nachtberichte fallen still aus, und man merkt es erst, wenn ein Kunde anruft. So überwachen Sie geplante Jobs rechtzeitig.

Vlado Pandžić

Vlado Pandžić · Gründer · Senior .NET-Architekt
Veröffentlicht · 6 Min. Lesezeit

Ein Szenario, das häufiger vorkommt, als jemand zugibt: Jede Nacht um 2 Uhr holt ein Job neue Bestellungen aus dem Webshop und trägt sie ins ERP ein. Er läuft seit Jahren, und niemand denkt an ihn.

Am Dienstag ändert der Partner, der den Webshop betreibt, die Zugangsdaten. Um 2 Uhr startet der Job, der Webshop weist ihn ab, und der Job endet. Still.

Am Freitag ruft ein Kunde an: Wo ist meine Ware? Erst dann schaut jemand nach und merkt, dass drei Tage Bestellungen nie im System angekommen sind.

Warum geplante Jobs still ausfallen

  • Sie laufen im Hintergrund. Kein Bildschirm, niemand schaut hin, mitten in der Nacht.
  • Der Fehler landet in einem Log, das niemand liest. Irgendwo auf einem Server gibt es eine Datei, in der genau steht, was passiert ist. Niemand öffnet sie.
  • Sie laufen über ein altes Werkzeug auf einem alten Server. Die Windows-Aufgabenplanung auf einem Server, von dem keiner mehr weiß, wer ihn eingerichtet hat.
  • Am tückischsten: Der Job endet „erfolgreich“, tut aber nichts. Er startet, meldet keinen Fehler und überträgt null Bestellungen. Alles sieht gut aus, und nichts ist gut.

Um welche Jobs es geht

Fast jedes Unternehmen hat mehrere solcher Jobs, ohne dass jemand sie je aufgelistet hat:

  • Import von Bestellungen aus dem Webshop oder aus Partnerportalen
  • Abgleich von Beständen und Preisen zwischen Systemen
  • Export von Daten an die Buchhaltung
  • nächtliche Berichte per E-Mail an die Geschäftsführung
  • Backups von Datenbanken und Dokumenten
  • Erneuerung von Zertifikaten und Bereinigung alter Daten

Jeder davon ist im Grunde das, worüber wir im Artikel über Systemintegration geschrieben haben: Automatisierung, die Handarbeit ersetzt. Aber eine Automatisierung, die still stoppt, ist schlimmer als Handarbeit, denn Handarbeit bemerkt wenigstens jemand.

Ein Log, das niemand liest, oder eine Warnung, die von selbst kommt

Log auf dem Server · niemand liest es

import-orders.log

02:00:01 Import started
02:00:03 Connecting to shop API
02:00:04 401 Unauthorized
02:00:04 Import finished

Dasselbe am Mittwoch, Donnerstag und Freitag.

Warnung · Teams, Dienstag 02:05

Bestellimport fehlgeschlagen

Der Webshop hat den Zugriff verweigert (401). Letzter erfolgreicher Import: Sonntag um 02:00, 164 Bestellungen.

Benachrichtigt: Vertriebsleitung · IT

Derselbe Fehler, zwei völlig unterschiedliche Folgen. Links drei Tage verlorene Bestellungen und verärgerte Kunden. Rechts weiß fünf Minuten nach dem Fehler jemand, was passiert ist, und bis zum Morgen ist es behoben.

Vier Fragen, die eine gute Überwachung stellt

Zu wissen, ob ein Job einen Fehler gemeldet hat, reicht nicht. Eine gute Überwachung prüft bei jedem Job vier Dinge:

  1. Ist er überhaupt gestartet? Wenn der Server ausgefallen ist oder jemand den Zeitplan geändert hat, gibt es keinen Fehler, weil gar nichts passiert ist.
  2. Ist er ohne Fehler durchgelaufen?
  3. Hat er getan, was er soll? Überträgt der Import sonst 120 bis 180 Bestellungen und heute null, stimmt etwas nicht, auch ohne Fehlermeldung.
  4. Wie lange hat er gedauert? Ein Job, der früher zwei Minuten brauchte und jetzt zwei Stunden, fällt wahrscheinlich morgen aus.

All das landet auf einem Bildschirm:

Job Letzter Lauf Ergebnis Status
Bestellimport aus dem Webshop heute 02:00 0 Bestellungen (sonst 120–180) Warnung
Export an die Buchhaltung gestern 23:00 nicht gestartet Fehler
Bestandsabgleich heute 03:00 2.412 Artikel In Ordnung
Nächtlicher Vertriebsbericht heute 06:00 an 4 Adressen gesendet In Ordnung

So merken Sie, dass ein Job steht: vier Wege

Es braucht nicht alles auf einmal. Man beginnt mit dem Einfachsten, und jeder nächste Weg fängt ab, was der vorherige übersieht.

  1. 1Der Job meldet seinen Ausfall
  2. 2Der Job meldet sich lebendig
  3. 3Prüfung des Ergebnisses
  4. 4Zentrale Überwachung
  1. Der Job meldet seinen Ausfall selbst. Tritt ein Fehler auf, schickt der Job eine E-Mail oder eine Teams-Nachricht mit einer Beschreibung, was passiert ist. Das sind ein paar Zeilen Code im bestehenden Job. Aber wenn der Job gar nicht startet, gibt es niemanden, der die Nachricht schickt.
  2. Der Job meldet sich lebendig. Am Ende jedes erfolgreichen Laufs meldet sich der Job bei einem externen Dienst zur Überwachung geplanter Jobs. Der Dienst weiß, dass er jede Nacht bis 2:30 Uhr eine Meldung erwartet, und schickt selbst eine Warnung, wenn keine kommt. So fällt auch ein ausgefallener Server oder ein geänderter Zeitplan auf, denn der Dienst wartet auf eine Meldung, die nie kam. Solche Dienste gibt es mehrere, mit kleinen monatlichen Kosten oder kostenlos für wenige Jobs.
  3. Prüfung des Ergebnisses. Morgens schaut eine Abfrage in der Datenbank, wie viele Bestellungen über Nacht angekommen sind, und vergleicht mit dem Üblichen. Null statt 150 heißt Warnung, auch wenn kein Job einen Fehler gemeldet hat. Nur so fällt der tückischste Fall auf.
  4. Zentrale Überwachung. Gibt es viele Jobs, senden alle ihre Daten an eine Stelle, zum Beispiel an Application Insights, über das wir im Artikel zur Anwendungsüberwachung geschrieben haben. Dort liegt der Bildschirm aus der Tabelle oben, mit Regeln wie: der Job ist seit 26 Stunden nicht erfolgreich gelaufen, er hat null Datensätze übertragen, er hat dreimal so lange gedauert wie sonst.
Weg Fehler Nicht gestartet 0 Datensätze Langsamer Job Aufwand
Job meldet seinen Ausfall ✓ – – – gering
Job meldet sich lebendig ✓ ✓ – – gering
Prüfung des Ergebnisses ✓ ✓ ✓ – gering bis mittel
Zentrale Überwachung ✓ ✓ ✓ ✓ mittel

Für die meisten Unternehmen decken der zweite und der dritte Weg zusammen fast alles ab, und sie sind in wenigen Tagen eingerichtet, ohne die Server anzufassen.

Müssen die Jobs nach Azure umziehen?

Nicht unbedingt. Die Überwachung kommt zu den Jobs dort, wo sie schon laufen: auf dem alten Server, in der Windows-Aufgabenplanung oder in der Anwendung. Ein Umzug in Azure Functions heißt, jeden Job neu zu schreiben und neu zu testen, und das ist keine Kleinigkeit.

Ein Umzug lohnt sich, wenn sich ohnehin etwas ändern muss: wenn der alte Server geht, zum Beispiel wegen des Support-Endes von Windows Server 2016, oder wenn der Job ohnehin überarbeitet wird. Dann bekommen Jobs in Azure Functions die Überwachung fast von selbst, und es gibt keinen Server mehr, der ausfällt und den Job mitnimmt. Wenn Sie einen Job doch nach Azure Functions verlagern, zeigt unser kostenloser Azure Functions Cron-Ausdruck Generator, wann er genau läuft.

Was Sie diese Woche tun können

Listen Sie alle geplanten Jobs im Unternehmen auf: was sie tun, wann sie laufen und wo. Beantworten Sie dann für jeden eine Frage: Wer wird benachrichtigt, wenn dieser Job ausfällt?

In den meisten Unternehmen lautet die häufigste Antwort „niemand“. Das heißt: Bei jedem dieser Jobs erfahren Sie es erst, wenn ein Kunde anruft.

Wie wir arbeiten

Genau das machen wir: Wir fügen bestehenden geplanten Jobs dort, wo sie laufen, eine Überwachung hinzu, damit Sie sofort wissen, wenn einer stoppt oder nicht tut, was er soll, und richten Warnungen ein, die die richtige Person erreichen. Einen Umzug nach Azure schlagen wir nur vor, wenn er sich lohnt. Wir beginnen mit einer Liste der Jobs und mit denen, die am meisten kosten, wenn sie stoppen. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Dieser Artikel dient nur der allgemeinen Information und ist keine Rechts-, Steuer-, Finanz- oder sonstige Fachberatung. Szenarien, Beispiele und Berechnungen dienen der Veranschaulichung. Nutzungsbedingungen und Haftungsausschluss.

Verwandte Artikel

© 2026 ProCoding — Alle Rechte vorbehalten.Impressum und DatenschutzHaftungsausschlussSplit, Kroatien