État actuel du site
Vérifiez si le site actif est enregistré comme disponible, indisponible, en délai d'attente ou injoignable avant d'ouvrir les détails.
Surveillance de disponibilité pour les sites SEO et commerciaux
Vérifiez que le site d'un projet Screpy est accessible, mesurez sa disponibilité et ses temps de réponse sur 30 jours, examinez les erreurs HTTP et le rétablissement des incidents, puis informez la bonne boîte de réception sans transformer l'uptime en promesse de classement.
TL;DR
Trop long ; non lu
Afficher le résumé Masquer le résumé
TL;DR
Trop long ; non lu
Qu'est-ce que Screpy Uptime Monitoring ?
Screpy Uptime Monitoring vérifie régulièrement le site public configuré pour un projet, enregistre sa disponibilité HTTP et son temps de réponse, puis résume les 30 derniers jours avec les incidents et les notifications par e-mail prises en charge. Il fournit des preuves de surveillance externe ; il ne diagnostique pas l'infrastructure et ne garantit pas la visibilité dans les recherches.
Configurer le contrôle du projet
- Screpy surveille l'URL publique configurée pour le projet actuel.
- Uptime Monitoring peut être activé ou désactivé dans les paramètres du projet.
- L'intervalle de contrôle disponible dépend du forfait actif.
- Une adresse de notification facultative peut recevoir les e-mails de panne pris en charge.
Lire l'état sur 30 jours
- L'état actuel affiche le résultat du dernier contrôle terminé.
- Le pourcentage d'uptime résume les contrôles réussis des 30 derniers jours.
- Le temps de réponse moyen utilise les contrôles réussis de la même période.
- La dernière vérification et le nombre total de contrôles rendent la fraîcheur visible.
Examiner les preuves des contrôles
- Les réponses HTTP 2xx et 3xx sont enregistrées comme disponibles.
- Les autres réponses HTTP, les délais d'attente et les erreurs de connexion restent distincts.
- Les contrôles récents incluent l'état, le temps de réponse, le code HTTP et l'horodatage.
- Les incidents conservent ensemble les horodatages de début de panne et de rétablissement.
Comprendre les limites
- Chaque projet surveille son site configuré, pas une liste arbitraire de points de terminaison.
- Les contrôles HTTP externes ne remplacent ni la surveillance de l'infrastructure ni celle des transactions.
- Screpy enregistre les symptômes et le rétablissement, sans prétendre analyser automatiquement la cause racine.
- La disponibilité facilite l'accès des robots, mais ne garantit ni l'indexation ni les classements.
Voyez disponibilité, temps de réponse et incidents dans une seule vue.
Commencez par l'état actuel, puis utilisez le résumé sur 30 jours, les contrôles récents, la chronologie des réponses et les horodatages des incidents pour décider si le site doit être examiné.
Pourcentage d'uptime sur 30 jours
Calculez la part des contrôles réussis pendant la fenêtre de 30 jours au lieu de juger la fiabilité sur une seule requête.
Temps de réponse moyen
Examinez le temps de réponse moyen des contrôles réussis de la même période pour distinguer disponibilité et latence de livraison.
Chronologie des temps de réponse
Suivez les mesures récentes dans un graphique et comparez les périodes lentes aux déploiements, événements de trafic ou changements d'infrastructure.
Contrôles HTTP récents
Inspectez l'état enregistré, le code HTTP, le temps de réponse, l'état d'erreur sûr et l'horodatage des contrôles récents.
Répartition des états
Séparez les résultats réussis, les pannes, les délais et les erreurs de connexion pour voir si un problème est isolé ou récurrent.
Historique des incidents et du rétablissement
Consultez les incidents ouverts et résolus avec leurs horodatages de début et de rétablissement sans perdre l'événement lorsque le site redevient disponible.
Notifications par e-mail
Envoyez des notifications de panne et de rétablissement prises en charge aux membres du projet et à une adresse facultative lorsque l'incident est admissible.
Surveillez le site public configuré pour chaque projet.
Screpy envoie des contrôles HTTP externes récurrents selon l'intervalle disponible du forfait actif, puis rattache le résultat au même espace de travail SEO.
- Utilisez l'URL déjà configurée dans le projet
- Enregistrez les réponses HTTP 2xx et 3xx comme disponibles
- Distinguez erreurs HTTP, délais d'attente et erreurs de connexion
Lisez uptime et temps de réponse comme une tendance.
La vue glissante sur 30 jours transforme les contrôles individuels en historique de fiabilité sans masquer le dernier résultat ni la fraîcheur des données.
- Consultez l'état actuel et le pourcentage d'uptime
- Comparez le temps moyen avec la série des réponses
- Inspectez les contrôles récents et toute la répartition des états
Gardez panne et rétablissement dans la même chronologie.
Un contrôle échoué ouvre ou actualise un incident et le contrôle réussi suivant enregistre sa résolution afin de conserver un début, une durée et un rétablissement clairs.
- Suivez séparément les incidents ouverts et résolus
- Conservez les horodatages de début et de résolution
- Envoyez les e-mails pris en charge de panne et de rétablissement
Mettez en place une boucle utile de surveillance de disponibilité.
Un contrôle est utile lorsque la cible est publique, que l'intervalle correspond à son importance, que les notifications atteignent une boîte responsable et que chaque incident se termine par un rétablissement vérifié.
- 01
Utilisez l'URL publique du projet
Choisissez une cible publique stable que visiteurs et robots doivent atteindre. Évitez les routes d'administration privées ou les chemins volontairement indisponibles.
- 02
Activez les contrôles et configurez l'intervalle
Activez Uptime Monitoring dans les paramètres, utilisez l'intervalle du projet et ajoutez éventuellement une adresse e-mail responsable.
- 03
Lisez la tendance sur 30 jours avant d'escalader
Comparez état actuel, uptime, historique des réponses, résultats HTTP et échecs répétés au lieu de déclarer une panne à partir d'un seul point.
- 04
Enquêtez et confirmez le rétablissement
Vérifiez déploiement, DNS, TLS, hébergement, pare-feu et application en dehors de Screpy, puis confirmez qu'un contrôle réussi ultérieur clôt l'incident.
Donnez la priorité aux sites où l'indisponibilité coûte réellement.
Utilisez des contrôles récurrents pour les projets dont la disponibilité affecte ventes, prospects, campagnes, accès client ou récupération du contenu public par les robots.
Sites générateurs de revenus
Gardez boutique, site de réservation, produit par abonnement ou site de prospects sous contrôles externes récurrents.
Sites de recherche organique
Surveillez le site public que robots et visiteurs organiques doivent atteindre avant que le contenu ou le référencement puisse compter.
Sites de lancement et de campagne
Suivez le site pendant lancements, migrations, refontes et campagnes actives lorsque le coût d'une indisponibilité est immédiat.
Portefeuilles multi-projets
Examinez l'uptime séparément pour chaque projet Screpy afin de gérer les sites clients ou de marque dans un seul flux.
Connaissez les limites d'un résultat d'uptime.
Screpy fournit des preuves HTTP externes et l'historique des incidents du site configuré. Utilisez infrastructure, journaux, tests transactionnels et données de recherche lorsque la question dépasse ce périmètre.
Une cible de site par projet
Uptime Monitoring vérifie l'URL publique configurée du projet Screpy ; ce n'est pas une liste générale de moniteurs de points de terminaison indépendants.
Contrôle externe, pas télémétrie d'infrastructure
Le résultat indique si la cible publique a répondu. Il n'inspecte ni CPU, mémoire, conteneurs, bases de données, réseaux privés ni journaux serveur.
Preuve d'incident, pas preuve de cause racine
Statut HTTP, délais et horodatages réduisent le champ d'enquête mais ne prouvent pas si DNS, TLS, hébergement, déploiement, pare-feu ou code était en cause.
Disponibilité ne signifie pas garantie SEO
Une page publique fonctionnelle est nécessaire aux visiteurs et au crawl, mais un uptime élevé ne garantit ni indexation, ni classements, ni trafic, ni revenus, ni conversions.
Utilisez le flux de santé du site adapté au problème.
Surveillez l'accessibilité dans le temps, auditez le site si les erreurs ou schémas de crawl se répètent, ou examinez les performances après stabilisation de la disponibilité.
Suivez l'état actuel, l'uptime sur 30 jours, l'historique des réponses, les contrôles HTTP récents et les incidents du site.
Explorez le site pour trouver les pages en échec récurrentes, les problèmes de redirection, les destinations cassées et les schémas techniques liés à l'incident.
Lancez des contrôles de performances en laboratoire lorsque le site est accessible mais que chargement ou réactivité nécessitent encore une enquête.
Documentation Screpy
Apprenez à surveiller la disponibilité d'un site
Suivez le guide Screpy pour choisir une URL publique utile, configurer l'intervalle et l'adresse selon le forfait, interpréter les preuves sur 30 jours et vérifier le rétablissement d'un incident.
Questions sur la surveillance de disponibilité, réponses.
Comprenez l'URL cible, la logique des statuts HTTP, l'intervalle, l'historique sur 30 jours, les temps de réponse, le rétablissement, la portée des notifications et la différence avec la surveillance complète de l'infrastructure.
Que mesure Screpy Uptime Monitoring ?
Screpy vérifie l'URL publique configurée d'un projet et enregistre disponibilité, code HTTP, temps de réponse, horodatage du contrôle et état d'erreur sûr. Le tableau de bord résume les 30 derniers jours avec uptime, réponse moyenne, contrôles récents, répartition des états et incidents.
Que considère Screpy comme disponible ou indisponible ?
Une réponse HTTP terminée dans la plage 200 ou 300 est enregistrée comme disponible. Les autres réponses sont enregistrées comme indisponibles ; les délais et autres échecs sont séparés en timeout ou erreur.
À quelle fréquence Screpy vérifie-t-il l'uptime ?
Screpy utilise l'intervalle configuré pour le projet. Les valeurs disponibles dépendent du forfait et certains forfaits permettent un intervalle d'une minute. Le tableau de bord affiche le dernier contrôle pour juger la fraîcheur.
Uptime Monitoring affiche-t-il l'historique des temps de réponse ?
Oui. La vue Uptime trace les temps récents et indique la moyenne sur 30 jours des contrôles réussis. Le temps de réponse est un contexte opérationnel, pas la performance complète de chargement ni l'expérience réelle.
Comment fonctionnent les incidents de panne et le rétablissement ?
Un contrôle échoué ouvre ou actualise l'incident courant. Lorsqu'un contrôle ultérieur réussit, Screpy résout l'incident ouvert et enregistre l'heure du rétablissement.
Screpy envoie-t-il des alertes de panne ?
Screpy peut envoyer par e-mail les événements de panne pris en charge aux membres du projet et à une adresse facultative. Un message de rétablissement peut suivre. Consultez la liste des incidents, car chaque échec ne produit pas forcément un e-mail.
La surveillance de disponibilité remplace-t-elle celle du serveur ou des transactions ?
Non. Screpy vérifie de l'extérieur le site public configuré. Il n'inspecte pas l'infrastructure privée et ne teste pas les parcours en plusieurs étapes comme connexion, recherche, formulaire ou paiement.
Une panne peut-elle affecter le crawl ou l'indexation ?
Les problèmes de disponibilité peuvent empêcher les robots de récupérer une page et les erreurs répétées peuvent réduire le crawl. Uptime Monitoring fournit des preuves, mais ne garantit pas quand un moteur explorera, indexera ou classera une URL.
Sachez quand le site d'un projet devient indisponible.
Activez les contrôles récurrents, adressez les e-mails d'incident à la bonne boîte, examinez les preuves sur 30 jours et vérifiez le rétablissement après correction.
Votre travail SEO avec un budget réduit
Découvrez comment Screpy réunit audits, positions, visibilité IA et suivi avec des limites claires.