render-debug

Render のデプロイをデバッグする

ログ、メトリクス、データベースクエリを使用して、デプロイの失敗を分析します。根本原因を特定し、修正を適用します。

このスキルを使用する場面

次の場合に、このスキルを有効にします：

• Render でデプロイが失敗する
• サービスが起動しない、または繰り返しクラッシュする
• ユーザーがエラー、ログ、デバッグについて言及する
• ヘルスチェックがタイムアウトする
• 本番環境でアプリケーションエラーが発生する
• パフォーマンスの問題（応答が遅い）
• データベース接続の問題

Render へのアクセス

ログ、メトリクス、データベースの状態を確認する前に、references/render-access.md に従ってアクセスを確立し、対象のワークスペースを確認してください。利用可能な場合は MCP を優先してください。CLI ではログとデプロイの状態を確認できますが、メトリクスと構造化されたデータベースクエリには MCP が必要です。

---

デバッグのワークフロー

失敗が設定またはシークレットに関係する場合は、サービス変数を確認または変更する前に references/environment-variables.md を読んでください。 失敗がデプロイ状態、ロールアウト、ヘルスチェック、再起動、ロールバック、またはシャットダウンに関係する場合は、診断する前に references/deployments.md を読んでください。

Step 1: 失敗したサービスを特定する

list_services()

MCP が設定されていない場合は、セットアップするか（推奨）、CLI で続行するかを尋ねます。その後、続行します。

失敗状態のサービスを探します。詳細を取得します：

get_service(serviceId: "<id>")

Step 2: ログを取得する

ビルド／デプロイログ（ほとんどの失敗）：

list_logs(resource: ["<service-id>"], type: ["build"], limit: 200)

ランタイムエラーログ：

list_logs(resource: ["<service-id>"], level: ["error"], limit: 100)

特定のエラーを検索する：

list_logs(resource: ["<service-id>"], text: ["KeyError", "ECONNREFUSED"], limit: 50)

HTTP エラーログ：

list_logs(resource: ["<service-id>"], statusCode: ["500", "502", "503"], limit: 50)

Step 3: エラーパターンを分析する

ログのエラーを既知のパターンと照合します：

エラー	ログパターン	一般的な修正
MISSING_ENV_VAR	KeyError, not defined	render.yaml または update_environment_variables に追加する
PORT_BINDING	EADDRINUSE	0.0.0.0:$PORT を使用する
MISSING_DEPENDENCY	Cannot find module	package.json/requirements.txt に追加する
DATABASE_CONNECTION	ECONNREFUSED :5432	DATABASE_URL と DB の状態を確認する
HEALTH_CHECK	Health check timeout	/health エンドポイントを追加し、ポートのバインドを確認する
OUT_OF_MEMORY	heap out of memory, exit 137	メモリを最適化するか、プランをアップグレードする
BUILD_FAILURE	Command failed	ビルドコマンドまたは依存関係を修正する

エラーパターンの全一覧：references/error-patterns.md

デプロイをまたいでエラーが繰り返される場合： 段階的な修正から、より広範な調査に切り替えます。そのエラー種別で考えられる原因（関連する環境変数、ビルド設定、依存関係、型エラーなど）をコードベース／設定全体で調べ、次の再デプロイ前にまとめて対処します。

Step 4: メトリクスを確認する（パフォーマンスの問題）

クラッシュ、応答の遅延、またはリソースの問題の場合：

get_metrics(
  resourceId: "<service-id>",
  metricTypes: ["cpu_usage", "memory_usage", "memory_limit"]
)

get_metrics(
  resourceId: "<service-id>",
  metricTypes: ["http_latency"],
  httpLatencyQuantile: 0.95
)

メトリクスの詳細ガイド：references/metrics-debugging.md

Step 5: データベースの問題をデバッグする

データベース関連のエラーの場合：

# Check database status
list_postgres_instances()

# Check connections
get_metrics(resourceId: "<postgres-id>", metricTypes: ["active_connections"])

# Query directly
query_render_postgres(
  postgresId: "<postgres-id>",
  sql: "SELECT state, count(*) FROM pg_stat_activity GROUP BY state"
)

データベースの詳細ガイド：references/database-debugging.md

Step 6: 修正を適用する

環境変数の場合：

update_environment_variables(
  serviceId: "<service-id>",
  envVars: [{"key": "MISSING_VAR", "value": "value"}]
)

コードを変更する場合：

1. ソースファイルを編集します
2. コミットしてプッシュします
3. 自動デプロイが有効な場合、デプロイが自動的にトリガーされます

Step 7: 修正を確認する

# Check deploy status
list_deploys(serviceId: "<service-id>", limit: 1)

# Check for new errors
list_logs(resource: ["<service-id>"], level: ["error"], limit: 20)

# Check metrics
get_metrics(resourceId: "<service-id>", metricTypes: ["http_request_count"])

---

すぐに使えるワークフロー

一般的なシナリオ向けに用意されたデバッグ手順：

シナリオ	ワークフロー
デプロイに失敗した	list_deploys → list_logs(type: build) → 修正 → 再デプロイ
アプリがクラッシュする	list_logs(level: error) → get_metrics(memory) → 修正
アプリの動作が遅い	get_metrics(http_latency) → get_metrics(cpu) → query_postgres
DB 接続	list_postgres → get_metrics(connections) → query_postgres
デプロイ後の確認	list_deploys → list_logs(error) → get_metrics

詳細なワークフロー：references/quick-workflows.md

---

クイックリファレンス

MCP ツール

# Service Discovery
list_services()
get_service(serviceId: "<id>")
list_postgres_instances()

# Logs
list_logs(resource: ["<id>"], level: ["error"], limit: 100)
list_logs(resource: ["<id>"], type: ["build"], limit: 200)
list_logs(resource: ["<id>"], text: ["search"], limit: 50)

# Metrics
get_metrics(resourceId: "<id>", metricTypes: ["cpu_usage", "memory_usage"])
get_metrics(resourceId: "<id>", metricTypes: ["http_latency"], httpLatencyQuantile: 0.95)

# Database
query_render_postgres(postgresId: "<id>", sql: "SELECT ...")

# Deployments
list_deploys(serviceId: "<id>", limit: 5)

# Environment Variables
update_environment_variables(serviceId: "<id>", envVars: [{key, value}])

CLI コマンド（代替手段）

render services -o json
render logs -r <service-id> --level error -o json
render logs -r <service-id> --tail -o text
render deploys create <service-id> --wait

---

参考資料

• Render へのアクセス： references/render-access.md
• 環境変数： references/environment-variables.md
• コンピューティングプラン： references/compute-plans.md
• デプロイ： references/deployments.md
• エラーパターン： references/error-patterns.md
• メトリクスのデバッグ： references/metrics-debugging.md
• データベースのデバッグ： references/database-debugging.md
• クイックワークフロー： references/quick-workflows.md
• ログ分析： references/log-analysis.md
• トラブルシューティング： references/troubleshooting.md

関連スキル

• render-deploy — Render に新しいアプリケーションをデプロイします
• render-monitor — サービスの健全性を継続的に監視します
• render-mcp — MCP サーバーのセットアップと機能の検出

最新ドキュメントの取得

このスキルで最新の Render ドキュメントを参照するよう指示された場合は、次の手順に従ってください。

1. curl など、利用可能な URL 取得ツールまたは HTTP クライアントを使って、リンク先の Markdown ドキュメントを直接取得します。ウェブ検索の要約で代用しないでください。
2. 取得に成功し、想定どおりのドキュメントが返されたことを確認してから、内容を読みます。ファイルの保存やパスの表示だけでは不十分です。
3. リクエストに失敗した場合や、ツールで Markdown のレスポンスを読み取れない場合は、リンク先の HTML 版を開いて読みます。
4. どちらの形式も取得できない場合は、最新の資料を利用できないことを明示し、スキル内の該当トピックに固有の代替手順に従います。安定した制約についてのみ同梱のガイダンスを使用し、変更される可能性のあるプラットフォームの詳細を推測しないでください。

複数の資料が必要な場合は、それぞれにこの手順を適用し、確認できたドキュメントと利用できないドキュメントを区別してください。