Commencez par vérifier les symptômes. Pour faire contrôler une instance, une facture ou un nœud, connectez-vous au portail et ouvrez un ticket. Vous n’avez pas encore de location ? Découvrez les offres.
Les seuls canaux d’assistance sont les tickets du portail et l’e-mail. Même en cas d’urgence, signalez le problème par ticket et sélectionnez la priorité urgente : inutile de chercher un autre moyen de nous contacter.
Pour une connexion SSH impossible, une instance qui présente un problème, un renouvellement, une vérification de paiement ou une demande de contrôle des journaux côté nœud. Indiquez l’identifiant de l’instance, l’heure de début, l’impact et les vérifications déjà effectuées.
Objectif de première réponsePriorité élevée : sous 4 heures ; demande standard : sous 1 jour ouvré.
Vous n’avez pas encore d’instance ou souhaitez vérifier la compatibilité d’un modèle ou les achats pour votre équipe ? Écrivez à support@zshmac.com. Précisez l’usage prévu, le nombre d’instances, le nœud souhaité et la durée envisagée.
Objectif de première réponseRéponse les jours ouvrés. Pour un incident sur une instance existante, ouvrez plutôt un ticket avec son identifiant.
Si l’instance ne répond plus du tout, si plusieurs modes de connexion échouent ou si vous suspectez un incident sur le nœud, ouvrez un ticket dans le portail avec la priorité urgente. Ne lancez pas plusieurs réinstallations si l’état des données n’est pas confirmé.
Objectif de première réponsePriorité urgente : sous 1 heure. Indiquez également la dernière heure à laquelle l’instance était accessible.
Les délais de réponse sont des objectifs de prise en charge, pas des délais garantis de résolution. Les informations sur l’instance dans le ticket nous aident davantage que plusieurs e-mails successifs.
Tous les nœuds proposés fonctionnent 365 jours par an. La disponibilité est calculée par mois civil. En cas d’interruption, indiquez dans votre ticket la période concernée, l’identifiant de l’instance et les symptômes afin que nous puissions vérifier les journaux du nœud.
Si la disponibilité du mois est inférieure à 99,9 %, une compensation sous forme de crédit sur le compte est calculée au prorata de la durée d’indisponibilité. Faites votre demande par ticket dans le portail, dans les 7 jours suivant la fin du mois. Les cas de force majeure et les incidents dus aux opérations de l’utilisateur ne sont pas comptabilisés comme indisponibilité du service.
Valeur indicative, et non historique de disponibilité. Consultez les annonces de service et les tickets dans le portail pour connaître les incidents et leur impact au cours des 90 derniers jours.
Suivez les étapes dans l’ordre et notez l’heure du problème ainsi que le message d’erreur exact. Si vous avez besoin d’aide, ajoutez les résultats au même ticket pour éviter de reprendre les vérifications depuis le début.
| Problème | Vérifications et informations à fournir |
|---|---|
| Délai d’attente dépassé pour SSH | Dans le portail, vérifiez d’abord l’état de l’instance et l’adresse de connexion actuelle, puis testez l’accès au port depuis votre réseau local. Vérifiez votre VPN, votre proxy et les règles du pare-feu. Si le port répond mais que l’authentification échoue, vérifiez le nom d’utilisateur, les permissions de la clé et toute modification récente des identifiants. Joignez au ticket l’heure de la tentative, le réseau de sortie et le message d’erreur complet. |
| Écran noir ou résolution incorrecte dans VNC | Vérifiez d’abord si SSH fonctionne encore afin de distinguer un problème de session de bureau d’une instance inaccessible. Reconnectez le partage d’écran et vérifiez la résolution et les couleurs dans le client. Si l’écran reste noir après reconnexion, indiquez le type de client, l’heure du problème et si des commandes restent exécutables via SSH. Ne réinstallez pas le système en premier recours. |
| Erreur de certificat ou de profil de provisionnement Xcode | Vérifiez la version de Xcode sélectionnée, la cible de build et la configuration de signature. Contrôlez la date d’expiration du certificat, le déverrouillage du trousseau ainsi que la correspondance entre l’identifiant de l’app et le périmètre du profil de provisionnement. Pour la CI, vérifiez également que le compte exécutant le runner peut accéder au trousseau requis. Joignez des logs de build expurgés des données sensibles et ne transmettez jamais de clé privée. |
| Espace disque insuffisant | Exécutez d’abord df -h pour vérifier l’espace disponible sur le volume, puis examinez DerivedData, les simulateurs, les archives et les images de conteneurs. Avant toute suppression, vérifiez si les fichiers servent de cache de build ou de traces de livraison. Pour les charges de travail qui augmentent continuellement, consultez les offres et options d’extension du stockage. |
| Runner auto-hébergé hors ligne | Vérifiez d’abord que l’instance est en ligne et peut accéder à votre plateforme de gestion de code. Contrôlez ensuite le processus du runner, les droits de son compte de service, son jeton d’enregistrement et la file d’attente des tâches. Si seul le build échoue, conservez les logs et le code de sortie. Si l’instance est également inaccessible, ouvrez un ticket en suivant la procédure de dépannage SSH. |
Ces étapes servent uniquement au diagnostic et ne modifient pas automatiquement l’instance. Ne publiez pas d’identifiants de connexion, de clés privées de certificat ni de données de paiement complètes.
Ces deux opérations se lancent depuis la page de l’instance après connexion. Vérifiez d’abord si vous devez conserver l’état actuel du système, puis choisissez la suite.
Dans le portail, ouvrez l’instance concernée, vérifiez le modèle et le nœud, puis assurez-vous qu’aucun build, transfert ou enregistrement de fichier n’est en cours avant de lancer le redémarrage. Celui-ci interrompra les connexions SSH et VNC ainsi que les tâches en cours. Une fois le système rétabli, reconnectez-vous et vérifiez vos services.
La durée dépend de l’état d’arrêt du système et des tâches en cours. Si l’instance tarde à redémarrer, notez l’heure de l’opération et ouvrez un ticket.
Sauvegardez vos dépôts, certificats, fichiers de configuration et artefacts de build en dehors de l’instance. Vérifiez ensuite l’instance dans le portail et confirmez la réinstallation de macOS. Cette opération efface les données de l’instance : vous devrez recréer l’environnement, le cache et les configurations locales.
La durée dépend de l’installation du système et de l’état de livraison. Fiez-vous à la progression et aux identifiants affichés dans le portail et ne relancez pas l’opération pendant son exécution.
Avant de renouveler, vérifiez l’instance, la durée et la facture. Si vous décidez de résilier, effectuez d’abord une sauvegarde externe et arrêtez les pipelines qui dépendent de cette machine. Le disque sera effacé après la résiliation : l’instance ne doit pas servir de sauvegarde à long terme. Pour vérifier la résiliation ou la facturation, connectez-vous au portail et ouvrez un ticket.
Les sujets ci-dessous vous orientent dans la base de connaissances, mais ne permettent pas de signaler un incident. Pour consulter les logs de votre instance, modifier une facture ou vérifier un incident sur un nœud, passez par le portail.
Configurez votre clé SSH, vos outils en ligne de commande et le partage d’écran, puis vérifiez que l’interface graphique est accessible.
Lire le guide de démarrageDistinguez la version de la chaîne d’outils, le cache DerivedData, les paramètres de build et l’état du runner. Conservez des logs permettant de reproduire le problème.
Voir les articles techniquesVérifiez les droits d’accès au trousseau, la validité des certificats et la correspondance avec le profil de provisionnement. Supprimez les informations sensibles avant de partager des logs.
Voir les articles techniquesLorsque des conteneurs et des builds s’exécutent en parallèle, surveillez séparément la mémoire unifiée, le stockage et les processus en arrière-plan.
Voir les articles techniquesDéterminez d’abord la mémoire unifiée nécessaire au modèle et à sa fenêtre de contexte, puis choisissez le modèle d’instance et la durée adaptés.
Comparer les modèlesAjoutez au ticket initial l’impact actuel, l’heure du premier signalement et tout nouvel élément de preuve. Précisez que vous n’avez pas encore reçu de première réponse. Le suivi dans le même ticket conserve le contexte du diagnostic : évitez d’en créer plusieurs pour un même problème.
Si vous suspectez un incident sur un nœud, consultez les annonces de service après vous être connecté au portail, puis vérifiez dans votre ticket si votre instance est concernée. Les annonces décrivent les incidents communs ; le rétablissement de l’instance et la vérification d’une compensation se font dans le ticket.
Suivez le guide pour passer commande, récupérer vos identifiants de connexion et lancer votre premier build. Pour choisir une offre avant de vous lancer, écrivez à notre équipe.