app did not respond on / within 30s
Votre build a réussi mais l’application n’a jamais répondu à la vérification d’état. Par ordre de probabilité :
- N’écoute pas sur
$PORT. La cause la plus courante — un port codé en dur :
// ✗ hardcoded — fails the health check app.listen(3000); // ✓ reads the assigned port app.listen(process.env.PORT || 3000);
- Plantage au démarrage. Une variable d’environnement manquante (
DATABASE_URL, une clé API) lève une exception au départ. Le message d’échec du journal de build inclut la fin du journal d’exécution de votre application — lisez-le; la trace y est généralement. /n’est pas servable. Une application API-seulement qui répond 404 ou 500 à la racine échoue la vérification — un 5xx ne compte pas comme vivant. Réglez le chemin de vérification d’état du projet vers une route qui répond 200, ou ajoutez un gestionnaire/trivial.- Démarrage lent. Charger un gros modèle ou jeu de données au démarrage peut dépasser la fenêtre de 30 secondes — chargez le lourd paresseusement, après que le serveur écoute.
No package.json or index.html found.
Canner a regardé la racine du projet et n’a trouvé ni manifeste Node ni entrée statique. Habituellement :
- Monodépôt / application imbriquée : l’application vit dans un sous-dossier. Réglez le répertoire racine dans les paramètres du projet.
- Mauvais niveau d’archivage : votre archive contient un seul dossier enveloppant. Archivez le contenu, ou glissez le dossier lui-même sur la zone de dépôt.
- Le dépôt ne les contient réellement pas — vérifiez que vous avez poussé ce que vous croyez avoir poussé.
A lockfile is required to deploy
Les builds sont reproductibles par conception, ce qui exige package-lock.json, pnpm-lock.yaml, yarn.lock ou bun.lockb. Exécutez l’installation de votre gestionnaire de paquets localement et committez (ou incluez dans le téléversement) le fichier de verrouillage produit.
package-lock.json is out of sync with package.json
Vous avez modifié les dépendances sans réinstaller. Exécutez npm install localement, puis committez le fichier de verrouillage mis à jour et redéployez.
Could not detect a supported project
Les fichiers ne correspondent à aucun environnement connu de Canner : Node, Python, Go, Ruby, PHP, Rust ou HTML statique. S’il s’agit d’un projet Java/JVM, ce n’est pas encore pris en charge. S’il devrait être détecté, vérifiez le répertoire racine — la détection s’exécute sur la racine configurée.
out of memory
Le build a dépassé son budget mémoire (plafonné par forfait — voir les limites). Les gros builds Next.js avec vérification de types sont le coupable habituel — essayez typescript.ignoreBuildErrors avec une vérification de types séparée en CI, allégez les dépendances, ou passez à un forfait avec plus de mémoire de build.
Le téléversement échoue ou l’archive ne s’extrait pas
Un zip malformé (certains outils d’archivage macOS en produisent) est la cause habituelle. Utilisez .tar.gz, ou glissez le dossier lui-même — la zone de dépôt l’empaquette correctement. Les téléversements interrompus (Part terminated early) ne sont qu’une connexion instable — réessayez.
Toujours bloqué?
Écrivez à hello@canner.ca avec le slug de votre projet — un humain qui voit les journaux de build répond.