Zum Inhalt springen
use-cases / mute-flaky-job / hero
CRON · MANAGED ENTRIES · PATCH

Den flakigen Job stummschalten, ohne ihn zu verlieren

Der stündliche Metrics-Export schlägt seit drei Tagen fehl. Du hast heute Nacht Bereitschaft. PATCH den Managed-Cron-Eintrag mit enabled:false — Schedule, Befehl und Kommentar bleiben alle erhalten. Der Job ist in einem definierten Zustand: vorhanden und stummgeschaltet, wartet darauf, dass jemand ihn repariert.

Cron-Docs lesen

der Toggle ist nur ein PATCH · der Eintrag verlässt die Liste nie

use-cases / mute-flaky-job / mechanism

Stumm ist ein einziges PATCH

Die Managed Entries von Hoody Cron sind eine JSON-Ressource: Jede Zeile hat eine id, einen Schedule, einen Befehl, einen Kommentar und ein enabled-Flag. enabled auf false zu kippen ist ein PATCH. Der Eintrag bleibt in der Crontab, damit die nächste Person ihn lesen und entscheiden kann, was zu tun ist.

terminal · on-call laptop
PATCH · stumm
# mute the flaky entry — entry stays in the crontab
curl -X PATCH \
  https://cron.containers.hoody.com/users/me/entries/e7d3 \
  -H "Content-Type: application/json" \
  -d '["enabled": false, "comment": "flaking on monday with prod-db — see #pager"]'

# response
HTTP/1.1 200 OK
{ "id":"e7d3", "enabled":false, "schedule":"0 * * * *",
  "command":"/srv/cron/metrics-export.sh", ... }
terminal · am nächsten Morgen
GET · prüfen
# the entry is still on the list — just not running
curl GET https://cron.containers.hoody.com/users/me/entries

HTTP/1.1 200 OK
[
  { "id":"a1f2", "enabled":true,  ... },
  { "id":"e7d3", "enabled":false, "comment":"flaking — see #pager" },
  { "id":"9b21", "enabled":true,  ... }
]
# present and muted — the on-call hand-off has somewhere to point

Das PATCH löscht, überschreibt oder verschiebt den Eintrag nicht — es kippt einen einzigen Boolean. Die Übergabe ist eine Zeile: 'metrics-export-Eintrag e7d3 ist stumm, siehe hoody-cron, bitte mal anschauen.'

use-cases / mute-flaky-job / states

Drei Zustände, ein Eintrag

Ein Eintrag in einer Hoody-Crontab befindet sich immer in genau einem von drei Zuständen. Jeder Zustand hat andere Konsequenzen dafür, wer morgen früh was weiß.

ENTRY · e7d3 · /srv/cron/metrics-export.shPATCH wechselt zwischen Zuständen — niemals destruktiv
ENABLED

Läuft nach Schedule, paged bei Fehler

Der Eintrag steht in der Crontab und der Kernel-Cron-Daemon nimmt ihn jede Stunde auf. Fehler wecken die Bereitschaft. Das ist der Default für gesunde Jobs.

MUTED

Vorhanden, pausiert, kommentiert

enabled:false. Der Eintrag steht weiterhin in der Crontab, sodass das Team Schedule, Befehl und Kommentar lesen kann. Der Cron-Daemon überspringt ihn. Kein Pager um 2 Uhr morgens, niemand vergisst, dass es ihn gibt.

DELETED

Weg — und der Kontext gleich mit

Sobald du DELETE schickst, verschwinden Schedule, Befehl, Kommentar, der Grund — alles aus der Crontab. Die nächste Bereitschaft hat nichts zum Greppen. Stumm ist die Wahl, die das Gedächtnis bewahrt.

Stumm ist der mittlere Zustand, für den die meisten Scheduler keinen Namen haben. Hoody Cron schon, weil enabled ein erstklassiges Feld am Managed Entry ist.

use-cases / mute-flaky-job / powers

Warum ein definierter Stumm-Zustand zählt

Wenn du einen Job heute Nacht nicht reparieren kannst, ist die Frage, welche Form seine Abwesenheit bis morgen annimmt. Stumm macht diese Form lesbar.

HAND-OFF

Die Bereitschafts-Nachricht ist eine Zeile

Statt einen Slack-Thread oder einen PR mit gelöschter Zeile reinzukopieren, ist die Nachricht die Eintrags-id. Die Bereitschaft von morgen öffnet die Cron-URL, liest den Kommentar und weiß, wo sie anfangen muss.

AUDIT

Jede Stummschaltung ist eine Zeile, keine Erinnerung

GET /entries gibt enabled:false zusammen mit dem Kommentar zurück. Bau ein Audit-Panel per Filter. Wer es stummgeschaltet hat, warum und wie lange ist her steht im JSON, nicht in jemandes DMs.

REVERSIBLE

Stumm aufheben ist das umgekehrte PATCH

Wenn das zugrundeliegende Problem behoben ist, setzt ein weiteres PATCH mit enabled:true den Eintrag zurück auf den Schedule. Kein Umschreiben des Cron-Ausdrucks, kein Tippfehler-Risiko, kein Commit-and-Deploy-Zyklus.

use-cases / mute-flaky-job / capacity

Was dir die Cron-API gibt

Zahlen kommen aus der Managed-Entries-Oberfläche von Hoody Cron, keine erfundenen Benchmarks.

  1. EINE METHODEPATCH

    PATCH /users/[user]/entries/[id] akzeptiert einen Partial-Body. Schick ["enabled":false] allein — Schedule, Befehl und Kommentar bleiben unangetastet.

  2. ERHALTENE FELDER5+1

    Fünf-Feld-Schedule, Befehl, Kommentar, expires_at und id bleiben über die Stummschaltung hinweg erhalten. Die Kernel-Crontab spiegelt den Eintrag weiterhin — nur vom Cron-Service auskommentiert.

  3. REWRITES0

    Keine Datei-Edits, kein PR, kein Deploy. Der Stumm-Round-Trip ist ein HTTP-Call aus jedem Terminal, auch dem auf deinem Handy.

Laut der Hoody Cron Managed Entries API: Jeder Eintrag trägt einen enabled-Boolean neben Schedule, Befehl, Kommentar und optionalem expires_at. PATCH akzeptiert Partial-Bodies.

use-cases / mute-flaky-job / punchline

Deaktiviert ist nicht gelöscht — der Eintrag wartet darauf, dass jemand ihn repariert.

heute Nacht · Bereitschaft · 23:14morgen · das Team · 09:00
WIE DER ALTE WORKFLOW AUSSAHvim crontab → Zeile auskommentieren → commit → PR → merge → deploysechs Schritte · verliert Kommentar-Kontext · Tippfehler-Risiko in einer müden Nacht
WIE ES JETZT AUSSIEHTcurl -X PATCH .../entries/e7d3 -d '["enabled":false]'ein PATCH · Eintrag bleibt in der Liste · Notiz reist mit
PATCH-Spec ansehen
use-cases / mute-flaky-job / replaces

Was das ersetzt

Die üblichen Wege, mit denen Teams eine flakige Cron-Zeile 'temporär' parken. Jeder davon ist entweder destruktiv, verlustbehaftet oder zwei PRs von der Produktion entfernt.

  • Crontab-Zeilen von Hand auskommentierenVerliert das strukturierte enabled-Flag · leicht zu vergessen
  • Eintrag löschen und 'sich erinnern'Schedule, Befehl und Grund verschwinden alle mit ihm
  • manuelle // FIXME-Kommentare im CodeLebt in einem Repo, nicht im Schedule, der läuft
  • Slack-Threads als On-Call-GedächtnisEine Woche durchsuchbar · danach ist es niemandes Job mehr
  • GitHub-Issues für stumm-aber-nicht-gelöschte JobsEin Issue für eine Sache, die noch in der Crontab steht — doppelter Zustand
  • Terraform-verwaltete Cron-ConfigsPlan, apply, deploy — für ein einziges Boolean-Feld
use-cases / mute-flaky-job / cta

Hör auf, flakige Jobs um 2 Uhr morgens zu löschen. Schalt sie stumm, hinterlass eine Notiz, und lass die Bereitschaft von morgen das JSON lesen.

Cron-Docs lesen
use-cases / mute-flaky-job / related

Lies die anderen