Wartung, SLA & proaktives Monitoring für Joomla und WordPress
Planbare Updates, geprüfte Backups und garantierte Reaktionszeiten — auf Wunsch mit proaktivem Uptime- und Security-Monitoring. Damit Ihre Website sicher, aktuell und erreichbar bleibt.
So arbeiten wir
-
1
Onboarding & Inventur
Zu Beginn nehmen wir Ihre Website vollständig auf: CMS-Version (Joomla, WordPress oder andere), installierten Extensions/Plugins mit Versionstand, PHP- und Datenbankversion, Hosting-Konfiguration (Dateirechte, PHP-FPM-User, Backup-Einstellungen). Wir prüfen den Ist-Zustand auf offensichtliche Sicherheitsmängel: veraltete Komponenten, unnötige Admin-Konten, schwache Passwörter, fehlende HTTPS-Konfiguration. Das Ergebnis ist eine dokumentierte Baseline, die als Referenz für alle späteren Änderungen dient. Beim Onboarding richten wir auch den Monitoring-Zugang ein und definieren gemeinsam die Kontaktpersonen und Eskalationswege.Resultat: Vollständige Inventarliste, dokumentierter Ist-Zustand, Monitoring konfiguriert und Eskalationswege definiert.
-
2
Geplante Updates & Backups
Das Herzstück des SLA-Betriebs sind regelmässige, geplante Wartungsfenster. CMS-Core-Updates (Joomla, WordPress) und alle Extensions/Plugins werden zeitnah nach Release geprüft, getestet und eingespielt — nicht blind automatisiert, sondern kontrolliert. Vor jedem Update wird ein vollständiges Backup erstellt (Dateien + Datenbank). Backups werden auf Integrität geprüft: Lässt sich der Dump importieren? Sind alle Dateien vollständig enthalten? Wir speichern Backups getrennt vom Produktiv-Server — lokale Backups auf dem Hosting-Account allein genügen nicht. Das Backup-Intervall richtet sich nach dem Paket — von monatlich (Basic) bis wöchentlich (Pro/Managed), jeweils mit geprüftem Restore.Resultat: CMS und Extensions aktuell, geprüfte Backups an mindestens zwei Speicherorten mit dokumentiertem Zeitstempel.
-
3
Proaktives Monitoring (auf Wunsch)
Über das reine Update-Management hinaus bieten wir Uptime-Monitoring (HTTP-Check alle 1–5 Minuten, Alarmierung bei Ausfall per E-Mail/SMS) und Security-Monitoring (regelmässige Dateiintegritätsprüfung gegen Checksummen der letzten sauberen Version, Prüfung auf bekannte Malware-Signaturen). Das Security-Monitoring erkennt neu auftauchende Backdoors oder injizierte Dateien frühzeitig — bevor Google die Website auf die Safe-Browsing-Blacklist setzt. Uptime-Monitoring deckt nicht nur Ausfälle ab, sondern auch langsame Ladezeiten (Threshold-Alerts) und abgelaufene SSL-Zertifikate (Ablaufwarnung 30 Tage vor Ablauf). Dieses Monitoring ist die erste Verteidigungslinie gegen das, was wir im Hack-Bereinigung-Service beheben.Resultat: Aktives Monitoring konfiguriert, Alerting getestet, Basiswerte (Ladezeit, Zertifikatsablauf) dokumentiert.
-
4
Reporting & SLA-Reaktion
Transparenz ist ein Kernelement des SLA-Betriebs. Monatliche Reports dokumentieren: durchgeführte Updates mit Versionvergleich vorher/nachher, Backup-Status, Uptime-Wert (falls Monitoring aktiv), aufgetretene Alerts und deren Behebung. Bei Störungen gilt die vertraglich definierte Reaktionszeit — je nach Paket zwischen 4 und 24 Stunden. Kritische Ausfälle (Website down, aktiver Hack) werden sofort priorisiert. Für die Infrastruktur, auf der Ihre Website läuft, finden Sie Details auf unserer vServer-Seite.Resultat: Monatlicher Report zugestellt, SLA-Reaktionszeiten eingehalten und dokumentiert.
Was Sie erhalten
Regelmässige Updates
CMS-Core, Extensions und Plugins werden kontrolliert — nicht blind automatisiert — aktuell gehalten. Jedes Update wird mit Backup abgesichert.
Geprüfte Backups
Vollständige Backups (Dateien + Datenbank) mit Integritätsprüfung, off-server gespeichert, mit definierten Aufbewahrungsintervallen.
Uptime-Monitoring
HTTP-Checks im Minutentakt, sofortige Alarmierung bei Ausfällen, SSL-Zertifikat-Ablaufwarnung 30 Tage im Voraus.
Security-Monitoring
Dateiintegritätsprüfung und Malware-Scan erkennen injizierte Backdoors frühzeitig — bevor Suchmaschinen die Website blacklisten.
Garantierte Reaktionszeiten
Vertraglich definierte Reaktionszeiten je nach Paket (4–24 Stunden), sofortige Priorisierung bei kritischen Ausfällen oder aktiven Hacks.
Transparentes Reporting
Monatlicher Report mit durchgeführten Updates, Backup-Status, Uptime-Wert und Dokumentation aller Massnahmen und Vorfälle.
Warum reaktive Wartung zu teuer ist
Viele KMU warten mit CMS-Updates, bis etwas nicht mehr funktioniert. Das ist verständlich — Updates können Probleme verursachen, und ohne Monitoring merkt man eine Verbesserung sowieso nicht. Aber die Rechnung ist trügerisch: Ein einziger Hack-Vorfall kostet in der Bereinigung, im Imageschaden und in der Ausfallzeit ein Vielfaches dessen, was ein Jahr SLA-Betreuung kostet.
Joomla und WordPress sind die am häufigsten angegriffenen CMS — nicht weil sie schlecht sind, sondern weil sie weit verbreitet sind und viele Installationen nicht aktuell gehalten werden. Automatisierte Scanner finden veraltete Plugin-Versionen innerhalb von Stunden nach Bekanntwerden einer Lücke. Wer Updates regelmässig und kontrolliert einspielt, ist ausserhalb dieses Angriffsfensters.
Das Monitoring ergänzt die Updates: Selbst wenn eine Lücke ausgenutzt wird, erkennt ein Dateiintegritäts-Scan die neu eingebrachte Backdoor-Datei innerhalb des nächsten Scan-Zyklus — lange bevor Google die Website blacklistet. Was danach zu tun ist, beschreibt unser Vorgehen zur Hack- und Malware-Bereinigung. Die Infrastruktur, auf der alles läuft, finden Sie auf der vServer-Seite.
Was hier steht — und was auf der Joomla-Seite
Diese Seite beschreibt das Gerüst, das unabhängig vom eingesetzten System gilt: Überwachung, garantierte Reaktionszeiten, Reporting und Eskalationswege. Es greift für Joomla, WordPress und andere Systeme gleichermassen, weil ein Ausfall ein Ausfall bleibt, egal was darunter läuft.
Wo sich die Systeme tatsächlich unterscheiden, ist die Update-Mechanik. Joomla versioniert Core und Erweiterungen über einen eigenen Update-Server, Template-Overrides greifen tief in die Darstellung ein, und eine aufgegebene Komponente hat seltener einen direkten Nachfolger als bei WordPress. Wer Joomla wartet wie WordPress, übersieht genau diese Stellen. Was daraus folgt — Akeeba-Backups mit Restore-Test, Überwachung des Pflegestatus jeder Erweiterung, Joomla-spezifische Härtung und der begleitete Weg von Joomla 3 auf das aktuelle Joomla 6 — steht auf der Seite zur Joomla-Wartung.
Es sind dieselben Pakete und derselbe Vertrag. Die Aufteilung dient der Lesbarkeit, nicht der Abrechnung.
Unsere Pakete
Basic
- Core- & Plugin-/Extension-Updates (monatlich)
- Monatliches Backup mit Restore-Test
- Verfügbarkeits-Check
- Update-Report per E-Mail
- Reaktionszeit: 2 Werktage
Pro
- Alles aus Basic
- Wöchentliches Backup
- Uptime-Monitoring 24/7
- Priorisierter Support
- Reaktionszeit: 1 Werktag
- Quartals-Sicherheitsreview
Managed
- Alles aus Pro
- Proaktives Security-Monitoring (Malware-Scan)
- Updates zuerst auf Staging getestet
- Garantierte SLA-Reaktionszeit: 4 Std.
- Monatlicher Performance- & Security-Report
- Persönlicher Ansprechpartner
Häufige Fragen
-
Was ist in einem SLA-Vertrag enthalten?
Ein SLA (Service Level Agreement) bei Cyberdine umfasst regelmässige CMS-Updates (Core + Extensions), Backups mit Integritätsprüfung, optionales Uptime- und Security-Monitoring sowie vertraglich definierte Reaktionszeiten bei Störungen. Der genaue Umfang — Update-Frequenz, Backup-Intervall, Monitoring-Intensität, Reaktionszeit — richtet sich nach dem gewählten Paket. Die Pakettabelle auf dieser Seite zeigt die konkreten Leistungen. Was der SLA nicht enthält: neue Funktionen, grössere Anpassungen am Design oder Content-Pflege. Diese werden separat beauftragt.
-
Was bedeutet proaktives Monitoring?
Proaktives Monitoring heisst, dass wir Probleme erkennen, bevor Sie oder Ihre Kunden sie bemerken. Das umfasst Uptime-Checks (Ist die Website erreichbar?), Performance-Alerts (Ladezeit über Schwellenwert?), SSL-Ablaufwarnungen (Zertifikat läuft in 30 Tagen ab), und Security-Scans (Wurden Dateien unerwartet verändert?). Ohne Monitoring erfahren Sie von einem Ausfall erst, wenn ein Kunde Sie anruft. Mit Monitoring erfahren wir es oft innerhalb von Minuten — und können handeln, bevor es eskaliert.
-
Für welche CMS gilt das SLA-Monitoring?
Primär betreuen wir Joomla (alle aktuellen 4.x- und 5.x-Versionen) und WordPress. Joomla-Altinstallationen (3.x) können betreut werden, solange sie sicherheitstechnisch updatefähig sind; für End-of-Life-Versionen empfehlen wir eine Migration. Bei anderen CMS (Typo3, Drupal) oder massgeschneiderten PHP-Applikationen besprechen wir den Scope individuell — das Prinzip (Updates, Backups, Monitoring) ist übertragbar, der Aufwand variiert. Diese Seite beschreibt das CMS-unabhängige Gerüst; was speziell für Joomla gilt — Update-Server, Akeeba-Backups, Erweiterungs-Lebenszyklus und Joomla-Härtung — steht unter Services in der Joomla-Wartung.
-
Kann ich den SLA-Vertrag monatlich kündigen?
Ja, unsere SLA-Verträge laufen monatlich und sind monatlich kündbar, ausser es wird eine längere Laufzeit vereinbart. Wir setzen auf Kundenbindung durch Qualität, nicht durch Vertragsfallen. Bei Kündigung erhalten Sie eine vollständige Dokumentation des Ist-Zustands (installierte Versionen, Backup-Standorte, Monitoring-Konfiguration), damit ein Wechsel ohne Wissensverlust möglich ist.
-
Was passiert, wenn meine Website trotz SLA gehackt wird?
Kein SLA kann einen Angriff mit hundertprozentiger Sicherheit ausschliessen — Zero-Day-Lücken, gestohlene Zugangsdaten oder Fehler im Entwicklerumfeld können auch bei laufender Betreuung vorkommen. Was der SLA-Betrieb sicherstellt: Der Schaden wird früh erkannt (Security-Monitoring), saubere Backups ermöglichen eine schnelle Wiederherstellung, und die Reaktionszeit ist vertraglich garantiert. Im Ernstfall greift dann die Hack-Bereinigung mit unserem bewährten Ablauf zur schnellen Wiederherstellung sauberer Zustände.
-
Übernehmt ihr auch die Betreuung einer Website, die aktuell bei einem anderen Anbieter liegt?
Ja. Viele Kunden kommen zu uns, nachdem ihr bisheriger Betreuer nicht mehr verfügbar ist oder die Website jahrelang ohne Updates geblieben ist. Beim Onboarding erheben wir den Ist-Zustand, bringen das System auf einen sicheren Stand und übernehmen dann den laufenden Betrieb. Ein Hosting-Wechsel zu Cyberdine ist nicht zwingend erforderlich, aber oft sinnvoll — unsere Infrastruktur ist speziell auf sichere, isolierte PHP-Umgebungen ausgelegt.
Bereit loszulegen?
Wir beraten Sie unverbindlich und erstellen ein massgeschneidertes Angebot.