Website-Monitoring mit GitHub Actions
Ein Schritt nach deinem Deploy genügt. Relvato führt deine Monitore auf der Live-Website aus und lässt den Job fehlschlagen, wenn einer ein Problem findet: ein kaputter Checkout, eine Seite, die anders aussieht, ein verwundbares Plugin, ein SEO-Rückschritt, eine fehlende Rechtsseite.
Die Action nutzt die API von Relvato, die in jedem Tarif enthalten ist, auch in Free. Sie braucht eine Website mit nachgewiesenem Eigentum und einen API-Schlüssel mit Vollzugriff.
In drei Schritten startklar
In GitHub musst du keine App installieren: Die Action ruft die API von Relvato mit einem Schlüssel auf, den du als Repository-Secret aufbewahrst.
Weise nach, dass die Website dir gehört
Füge die Website in Relvato hinzu und weise ihr Eigentum mit dem WordPress-Plugin, einem DNS-Eintrag oder einem Meta-Tag nach. Die API führt Monitore nur auf nachgewiesenen Websites aus.
Speichere einen Schlüssel mit Vollzugriff als Secret
Öffne in Relvato „API access“ und erstelle einen Schlüssel mit Vollzugriff. Öffne in GitHub Settings → Secrets and variables → Actions und speichere ihn als Repository-Secret namens RELVATO_API_KEY.
Füge den Schritt nach deinem Deploy hinzu
Füge Relvato/relvato-action@v1 mit dem Schlüssel und deiner Website zu deinem Workflow hinzu. Die Action wartet auf die Läufe und lässt den Job fehlschlagen, wenn ein Monitor ein Problem findet.
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.examplesite nimmt die Domain der Website (myshop.example) oder ihre Site-ID in Relvato. Ein Schlüssel mit Lesezugriff kann keine Läufe starten.
Starte sie, sobald der Deploy live ist
Relvato führt deine Monitore gegen die Adresse der Website aus. Der Schritt muss also nach dem Deploy kommen, wenn dieser in Produktion ist. Ein Preview-Deployment kann die Action nicht prüfen, bevor es übernommen wird.
Nach dem Deploy-Job im selben Workflow
Der Job verify wartet mit needs auf deploy. Hier führt er nur die Ablauf-Monitore aus (Checkout, Logins, Formulare) und lässt den Job nur bei einem hohen oder kritischen Problem fehlschlagen.
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh
verify:
needs: deploy
runs-on: ubuntu-latest
steps:
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.example
group: flow # checkout, logins, forms
min-severity: highNach einem Produktions-Deployment auf Vercel, Netlify oder einem anderen Host, der Deployments an GitHub meldet
Der Workflow startet bei deployment_status und läuft, sobald das Produktions-Deployment erfolgreich war: wenn es live ist, nicht vor der Übernahme. Der Name der Umgebung ist der, den dein Host meldet (Vercel nutzt Production).
on: deployment_status
jobs:
verify:
if: github.event.deployment_status.state == 'success' && github.event.deployment.environment == 'Production'
runs-on: ubuntu-latest
steps:
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.exampleWas ein Lauf aus deinem Workflow tut
Er schaut auf die Live-Website
Relvato führt die Monitore gegen die Adresse deiner Website aus. Setze den Schritt hinter den Deploy in Produktion: Ein Preview-Deployment lässt sich vor der Übernahme nicht prüfen.
Er zählt wie „Run now“
Jeder Lauf zählt zu den monatlichen Läufen deines Tarifs, einer pro Monitor. Ein gefundenes Problem wird auch über die Kanäle in „Alert settings“ gemeldet, wie bei jedem Lauf, den du von Hand startest.
Nicht gelaufen ist eine Warnung
Hat eine Firewall oder ein Bot-Schutz Relvato blockiert, hat die Website nicht geantwortet oder ist das WordPress-Plugin veraltet, ist der Monitor eine Warnung, kein Fehlschlag: Über deinen Deploy sagt das nichts.
Nur, was ein Deploy berühren kann
Setze group, um eine Monitor-Gruppe wie flow oder security auszuführen, und min-severity auf den niedrigsten Schweregrad, der den Job fehlschlagen lassen soll.
Eingaben
| Eingabe | Standard | Was sie tut |
|---|---|---|
api-key | — | Ein Relvato-API-Schlüssel mit Vollzugriff. Pflicht. |
site | — | Die Domain der Website (myshop.example) oder ihre Site-ID in Relvato. Pflicht. |
group | jeder Monitor | Nur eine Monitor-Gruppe: uptime, flow (Checkout, Logins, Formulare), security, design, performance, seo, domain oder compliance. |
fail-on | issue | issue: fehlschlagen, wenn ein Monitor ein Problem findet. any: auch, wenn ein Monitor nicht laufen konnte (eine Firewall hat Relvato blockiert, die Website war down) oder die Zeit abgelaufen ist. never: nur berichten. |
min-severity | low | Der niedrigste Schweregrad, der den Job fehlschlagen lässt: warning, low, medium, high oder critical. |
timeout-minutes | 20 | Wie lange gewartet wird. Die Monitore einer Website laufen nacheinander, ein voller Satz kann also mehrere Minuten dauern. |
Ausgaben
| Ausgabe | Was sie enthält |
|---|---|
result | passed, issues, not-run oder timeout |
issues | Wie viele Monitore ein Problem ab min-severity gefunden haben |
not-run | Wie viele Monitore nicht laufen konnten |
runs | Jeder Lauf als JSON: id, monitor, outcome, severity, url |
site-url | Die Seite der Website in Relvato |
Berichten, ohne fehlzuschlagen
Mit fail-on: never schlägt der Job nicht fehl; ein späterer Schritt kann die Ausgabe result lesen.
- uses: Relvato/relvato-action@v1
id: relvato
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.example
fail-on: never
- run: echo "Relvato says ${{ steps.relvato.outputs.result }}"Lieber keinen Workflow schreiben?
Bei einer Website vom Typ „Any website / AI-built app“ kannst du das GitHub-Repository, aus dem du deployst, mit der Relvato-GitHub-App verbinden oder den Deploy-Webhook bei GitLab, Netlify, Railway oder Ghost einrichten. Relvato führt die Monitore der Website dann bei jedem Push oder Deploy erneut aus, und ein Problem erreicht dich über deine üblichen Alarme. Die Action ist für den Fall, dass du das Ergebnis im Workflow selbst willst und der Job daran fehlschlagen soll.
Die GitHub Action, kurz erklärt
Welche Tarife können die GitHub Action nutzen?
Jeder Tarif, auch Free: Die Action nutzt die API von Relvato, die jeder Tarif hat. Jeder Lauf zählt zu den monatlichen Läufen deines Tarifs, einer pro Monitor. Nutze also group, um nur die Monitore auszuführen, die ein Deploy berühren kann.
Kann sie eine Preview auf Vercel oder Netlify vor der Übernahme prüfen?
Nein. Relvato führt deine Monitore gegen die Adresse der Website aus und sieht also, was live ist. Führe den Schritt nach dem Deploy in Produktion aus, zum Beispiel bei deployment_status, sobald das Produktions-Deployment erfolgreich war.
Was passiert, wenn ein Monitor nicht laufen konnte?
Das ist eine Warnung im Job, kein Fehlschlag: Eine Firewall oder ein Bot-Schutz hat Relvato blockiert, die Website hat nicht geantwortet oder das WordPress-Plugin ist veraltet. Über deinen Deploy sagt das nichts. Setze fail-on: any, wenn der Job auch daran fehlschlagen soll.
Bekomme ich für ein gefundenes Problem auch einen Alarm?
Ja. Ein Lauf aus einem Workflow zählt wie „Run now“ im Dashboard. Ein gefundenes Problem wird also auch über die Kanäle gemeldet, die du in „Alert settings“ eingestellt hast (E-Mail, Slack, Teams, Discord, Telegram, PagerDuty, Webhook).
Warum braucht sie einen Schlüssel mit Vollzugriff?
Ein Schlüssel mit Lesezugriff kann Ergebnisse lesen, aber keine Läufe starten. Erstelle in Relvato unter „API access“ einen Schlüssel mit Vollzugriff und speichere ihn als Repository-Secret namens RELVATO_API_KEY.
Wie lange dauert es?
Die Monitore einer Website laufen nacheinander, ein voller Satz kann also mehrere Minuten dauern. Die Action wartet bis zu timeout-minutes (standardmäßig 20). Laufen dann noch Monitore, ist das Ergebnis timeout. Das lässt den Job nur mit fail-on: any fehlschlagen.
Ich habe GitHub mit Relvato verbunden. Brauche ich die Action trotzdem?
Nur, wenn du das Ergebnis im Workflow willst. Die GitHub-App führt deine Monitore bei jedem Push erneut aus und meldet sich über deine Alarme. Die Action läuft, wann dein Workflow es sagt, zeigt jeden Monitor in der Job-Zusammenfassung und kann den Job fehlschlagen lassen.
Geht das auch ohne die Action?
Ja, über die REST-API: POST /api/v1/sites/{id}/scan (optional mit {"group": "flow"}), dann GET /api/v1/runs?siteId={id} abfragen, bis jeder Lauf finished ist, und seinen outcome (ok, issue, not-run) und severity lesen.
Weitere Wege, mit Relvato zu arbeiten
Wisse, dass der Deploy geklappt hat, bevor es deine Besucher merken
Weise das Eigentum der Website nach, erstelle einen Schlüssel mit Vollzugriff und füge deinem Workflow einen Schritt hinzu.