Site hors ligne : que vérifier en premier ?
Une panne peut venir de l’hébergement, du DNS, de TLS, de l’application ou du réseau. Commencez par isoler la couche en cause.
- Vérifiez depuis une autre connexion ou un système indépendant.
- Notez le statut HTTP ou l’erreur de connexion et contrôlez HTTPS.
- Inspectez ensuite l’hébergement, le DNS et les journaux applicatifs.
- Conservez l’heure de début et de rétablissement.
Un message du navigateur ne suffit généralement pas pour localiser la cause.
Comment vérifier si un site est en ligne ?
Voir la page d’accueil s’ouvrir ne suffit pas. Un contrôle utile combine accessibilité, statut HTTP, redirections et contexte temporel.
- Interrogez l’URL publique depuis un environnement indépendant.
- Vérifiez le statut HTTP final après redirections.
- Comparez plusieurs contrôles dans le temps.
- Automatisez le monitoring pour les sites critiques.
HTTP 200 ne garantit pas que les formulaires, paiements ou tâches de fond fonctionnent.
Vérifier un certificat SSL et éviter son expiration
HTTPS peut échouer si le certificat expire, ne correspond pas au domaine ou si la chaîne ne peut pas être validée.
- Vérifiez que HTTPS s’établit sans avertissement.
- Contrôlez la date d’expiration et planifiez le renouvellement.
- Après renouvellement, vérifiez le certificat réellement servi au public.
- Surveillez automatiquement l’expiration des sites importants.
Un certificat valide ne constitue pas un audit de sécurité complet.
Erreur HTTP 500 : que signifie-t-elle ?
HTTP 500 signifie que le serveur a rencontré une erreur interne inattendue. Le navigateur donne rarement la cause réelle.
- Notez l’heure, l’URL et le contexte.
- Consultez les logs applicatifs et serveur au même moment.
- Cherchez la première exception pertinente.
- Corrigez la cause puis retestez exactement la même route.
N’activez pas les détails de debug publiquement en production.
Trouver des erreurs WordPress au-delà de l’uptime
Un site WordPress peut rester accessible tout en générant des erreurs sur certaines pages ou actions.
- Identifiez la page ou l’action concernée.
- Consultez les logs PHP et WordPress sans exposer le debug au public.
- Reliez les erreurs aux changements récents.
- Après correction, retestez le parcours et l’accessibilité générale.
L’uptime et les erreurs applicatives mesurent deux réalités différentes.
Qu’est-ce que l’uptime et que signifie réellement 99,9 % ?
L’uptime est la part d’une période durant laquelle un service est disponible selon la définition du contrôle choisi.
- Définissez exactement l’URL et le statut considérés comme disponibles.
- Utilisez un intervalle de mesure constant.
- Conservez les débuts et fins d’incident.
- Ajoutez le contexte HTTP, SSL et applicatif si nécessaire.
99,9 % ne décrit pas les fonctions qui ne font pas partie du contrôle mesuré.