jpskill.com
🛠️ 開発・MCP コミュニティ

railway-logs

Railwayのデバッグや監視に必要なログにアクセスし、ビルド、デプロイ、実行時のログやHTTPログを分析、検索、外部エクスポートすることで、エラー調査やパフォーマンス改善に役立てるSkill。

📜 元の英語説明(参考)

Railway log access and analysis for debugging and monitoring. Covers build logs, deploy logs, runtime logs, HTTP logs, filtering, search, and external export. Use when viewing logs, debugging Railway deployments, investigating errors, analyzing HTTP requests, filtering log output, or exporting logs to external systems.

🇯🇵 日本人クリエイター向け解説

一言でいうと

Railwayのデバッグや監視に必要なログにアクセスし、ビルド、デプロイ、実行時のログやHTTPログを分析、検索、外部エクスポートすることで、エラー調査やパフォーマンス改善に役立てるSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o railway-logs.zip https://jpskill.com/download/9474.zip && unzip -o railway-logs.zip && rm railway-logs.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9474.zip -OutFile "$d\railway-logs.zip"; Expand-Archive "$d\railway-logs.zip" -DestinationPath $d -Force; ri "$d\railway-logs.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して railway-logs.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → railway-logs フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Railway Logs

アプリケーションのデバッグとモニタリングのために、Railway のログにアクセスして分析します。

概要

Railway は、デプロイメントのライフサイクル全体にわたって包括的なロギングを提供します。

  • Build Logs: ビルドプロセスの出力とコンパイル
  • Deploy Logs: デプロイメントのライフサイクルとヘルスチェック
  • Runtime Logs: アプリケーションの stdout/stderr 出力
  • HTTP Logs: リクエストのメタデータ (ステータス、パス、IP、タイミング)

すべてのログは、フィルタリング、検索をサポートし、長期保存のために外部システムにエクスポートできます。

キーワード: Railway logs, build logs, deploy logs, runtime logs, HTTP logs, log filtering, log search, debugging, monitoring, observability

この Skill を使用するタイミング

  • デプロイメントの失敗をデバッグする
  • ランタイムエラーを調査する
  • アプリケーションの動作を監視する
  • HTTP リクエストのパターンを分析する
  • 特定のイベントのログをフィルタリングする
  • ログを外部システム (Datadog, Axiom, BetterStack) にエクスポートする
  • ビルド/デプロイプロセスの理解
  • パフォーマンスの問題をトラブルシューティングする

前提条件: プロジェクトのリンク

重要: CLI ログには、アカウントトークンでリンクされたプロジェクトが必要です。

# 1. アカウントトークンを設定します (プロジェクトトークンではありません)
export RAILWAY_API_TOKEN=<your-account-token>

# 2. プロジェクト/環境/サービスをリンクします
railway link -p <PROJECT_ID> -e <ENVIRONMENT_ID> -s <SERVICE_ID>

# 例:
railway link -p f8fff4f1-1541-4a47-b509-0c30b9459275 \
             -e 3aa108f4-781d-433c-9eee-875c3dbe903d \
             -s 4b879f5f-5e42-4804-a67c-2a1ff2475cb3

# 3. リンクを確認します
railway status

詳細については、cli-commands.md を参照してください。


操作

操作 1: ビルドログの表示

ビルドプロセスのログにアクセスして、コンパイルと依存関係の問題をデバッグします。

CLI コマンド:

# ビルドログをストリームします (ライブ)
railway logs --build

# ビルドログの最後の 100 行
railway logs --build --lines 100

# 特定のデプロイメントのビルドログ
railway logs --build <DEPLOYMENT_ID>

# ビルドログをファイルにエクスポートします
railway logs --build --lines 500 > build-logs.txt

ダッシュボードからのアクセス:

  1. Railway ダッシュボード → サービスに移動します
  2. Deployments タブをクリックします
  3. デプロイメントを選択します
  4. Build Logs セクションを表示します

確認すべきこと:

  • ✅ 依存関係のインストール成功
  • ✅ ビルドステップの完了
  • ⚠️ 警告メッセージ (将来の問題を示す可能性があります)
  • ❌ ビルドの失敗とエラーメッセージ
  • 📊 ビルド時間 (最適化の機会)

一般的な問題: | 問題 | 解決策 | |-------|----------| | 依存関係がインストールされない | package.json/requirements.txt を確認してください | | ビルドタイムアウト | ビルドプロセスを最適化するか、タイムアウトを増やしてください | | ビルドコマンドがない | Railway ダッシュボードまたは railway.json で設定してください | | キャッシュの問題 | キャッシュなしで強制的にリビルドしてください |

関連項目: キャッシュの削除については、railway-troubleshooting を参照してください


操作 2: デプロイログの表示

デプロイメントのライフサイクルとヘルスチェックのステータスを監視します。

CLI コマンド:

# デプロイメントログをストリームします (ライブ)
railway logs --deployment

# デプロイログの最後の N 行
railway logs --deployment --lines 200

# ID による特定のデプロイメント
railway logs --deployment <DEPLOYMENT_ID>

# デプロイログのエクスポート
railway logs --deployment --lines 500 > deploy-logs.txt

ダッシュボードからのアクセス:

  1. Railway ダッシュボード → サービス → Deployments
  2. デプロイメントを選択します
  3. Deploy Logs セクションを表示します

デプロイメントのフェーズ:

  1. Building - コードのコンパイル
  2. Publishing - コンテナイメージの作成
  3. Deploying - インフラストラクチャへの展開
  4. Health Checking - サービスのヘルス状態の検証
  5. Active - デプロイメントが稼働中

ヘルスチェックのデバッグ:

# ヘルスチェックの失敗を表示します
railway logs --deployment | grep "health check"

# 一般的なヘルスチェックの問題:
# - ポートが正しく公開されていない
# - アプリケーションが 0.0.0.0 にバインドされていない
# - ヘルスエンドポイントが応答しない
# - 起動中にアプリケーションがクラッシュする

トラブルシューティング:

  • ヘルスチェックが失敗する場合、PORT 環境変数が正しいか確認してください
  • デプロイメントが停止する場合、起動プロセスをブロックしているものがないか確認してください
  • ロールバックが発生する場合、ヘルスチェックの設定を確認してください

操作 3: ランタイムログの表示

アプリケーションの stdout/stderr にアクセスして、ランタイムの動作をデバッグします。

CLI コマンド:

# ランタイムログをストリームします (ライブ、停止するには Ctrl+C)
railway logs

# 最後の N 行 (ストリーミングを停止します)
railway logs --lines 500

# 異なるサービス/環境をストリームします
railway logs --service backend --environment production

# Railway 構文でフィルタリングします
railway logs --filter "@level:error"
railway logs --lines 100 --filter "timeout"

# ローカルフィルタリングのために grep にパイプします
railway logs | grep ERROR

# パース用の JSON 出力
railway logs --json | jq 'select(.level == "error")'

ダッシュボードからのアクセス:

  1. Railway ダッシュボード → サービス → Observability
  2. Logs タブをクリックします
  3. フィルタリングによるリアルタイムログストリーム

構造化ロギングのベストプラクティス:

Railway は構造化 JSON ロギングをサポートしています。JSON を 1 行で出力してください。

// Node.js の例
console.log(JSON.stringify({
  level: 'error',
  message: 'Database connection failed',
  error: err.message,
  timestamp: new Date().toISOString(),
  userId: req.user?.id
}));
# Python の例
import json
import logging

logging.basicConfig(format='%(message)s')
logger = logging.getLogger()

logger.error(json.dumps({
    'level': 'error',
    'message': 'Database connection failed',
    'error': str(e),
    'timestamp': datetime.utcnow().isoformat(),
    'user_id': user_id
}))

サポートされているログレベル:

  • debug - 詳細な診断情報
  • info - 一般的な情報メッセージ
  • warn - 警告メッセージ (潜在的な問題)
  • error - エラーメッセージ (失敗)

利点:

  • すべての JSON フィールドは Railway ダッシュボードで検索可能です
  • より良いフィルタリングと分析
  • ログ集約ツールとの統合

操作 4: HTTP ログの表示

HTTP リクエストのパターンを分析し、API の問題をデバッグします。

ダッシュボードからのアクセス:

  1. Railway ダッシュボード → サービス → Observability
  2. HTTP タブをクリックします
  3. リクエストのメタデータを表示します

利用可能なメタデータ:

  • HTTP

(原文がここで切り詰められています)

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Railway Logs

Access and analyze Railway logs for debugging and monitoring applications.

Overview

Railway provides comprehensive logging across the deployment lifecycle:

  • Build Logs: Build process output and compilation
  • Deploy Logs: Deployment lifecycle and health checks
  • Runtime Logs: Application stdout/stderr output
  • HTTP Logs: Request metadata (status, path, IP, timing)

All logs support filtering, search, and can be exported to external systems for long-term retention.

Keywords: Railway logs, build logs, deploy logs, runtime logs, HTTP logs, log filtering, log search, debugging, monitoring, observability

When to Use This Skill

  • Debugging deployment failures
  • Investigating runtime errors
  • Monitoring application behavior
  • Analyzing HTTP request patterns
  • Filtering logs for specific events
  • Exporting logs to external systems (Datadog, Axiom, BetterStack)
  • Understanding build/deploy process
  • Troubleshooting performance issues

Prerequisites: Link Project First

Important: CLI logs require a linked project with Account Token:

# 1. Set Account Token (NOT project token)
export RAILWAY_API_TOKEN=<your-account-token>

# 2. Link project/environment/service
railway link -p <PROJECT_ID> -e <ENVIRONMENT_ID> -s <SERVICE_ID>

# Example:
railway link -p f8fff4f1-1541-4a47-b509-0c30b9459275 \
             -e 3aa108f4-781d-433c-9eee-875c3dbe903d \
             -s 4b879f5f-5e42-4804-a67c-2a1ff2475cb3

# 3. Verify link
railway status

See cli-commands.md for complete reference.


Operations

Operation 1: View Build Logs

Access build process logs to debug compilation and dependency issues.

CLI Commands:

# Stream build logs (live)
railway logs --build

# Last 100 lines of build logs
railway logs --build --lines 100

# Build logs for specific deployment
railway logs --build <DEPLOYMENT_ID>

# Export build logs to file
railway logs --build --lines 500 > build-logs.txt

Dashboard Access:

  1. Navigate to Railway Dashboard → Your Service
  2. Click Deployments tab
  3. Select deployment
  4. View Build Logs section

What to Look For:

  • ✅ Dependency installation success
  • ✅ Build steps completion
  • ⚠️ Warning messages (may indicate future issues)
  • ❌ Build failures and error messages
  • 📊 Build time (optimization opportunities)

Common Issues: | Issue | Solution | |-------|----------| | Dependencies not installing | Check package.json/requirements.txt | | Build timeout | Optimize build process or increase timeout | | Missing build command | Set in Railway dashboard or railway.json | | Cache issues | Force rebuild without cache |

See Also: railway-troubleshooting for cache busting


Operation 2: View Deploy Logs

Monitor deployment lifecycle and health check status.

CLI Commands:

# Stream deployment logs (live)
railway logs --deployment

# Last N lines of deploy logs
railway logs --deployment --lines 200

# Specific deployment by ID
railway logs --deployment <DEPLOYMENT_ID>

# Export deploy logs
railway logs --deployment --lines 500 > deploy-logs.txt

Dashboard Access:

  1. Railway Dashboard → Service → Deployments
  2. Select deployment
  3. View Deploy Logs section

Deployment Phases:

  1. Building - Compiling code
  2. Publishing - Creating container image
  3. Deploying - Rolling out to infrastructure
  4. Health Checking - Verifying service health
  5. Active - Deployment live

Health Check Debugging:

# View health check failures
railway logs --deployment | grep "health check"

# Common health check issues:
# - Port not exposed correctly
# - Application not binding to 0.0.0.0
# - Health endpoint not responding
# - Application crashing during startup

Troubleshooting:

  • Health check failing? Verify PORT environment variable
  • Deployment stuck? Check for blocking startup processes
  • Rollback occurring? Check health check configuration

Operation 3: View Runtime Logs

Access application stdout/stderr for debugging runtime behavior.

CLI Commands:

# Stream runtime logs (live, Ctrl+C to stop)
railway logs

# Last N lines (stops streaming)
railway logs --lines 500

# Stream different service/environment
railway logs --service backend --environment production

# Filter with Railway syntax
railway logs --filter "@level:error"
railway logs --lines 100 --filter "timeout"

# Pipe to grep for local filtering
railway logs | grep ERROR

# JSON output for parsing
railway logs --json | jq 'select(.level == "error")'

Dashboard Access:

  1. Railway Dashboard → Service → Observability
  2. Click Logs tab
  3. Real-time log stream with filtering

Structured Logging Best Practices:

Railway supports structured JSON logging. Output JSON on a single line:

// Node.js Example
console.log(JSON.stringify({
  level: 'error',
  message: 'Database connection failed',
  error: err.message,
  timestamp: new Date().toISOString(),
  userId: req.user?.id
}));
# Python Example
import json
import logging

logging.basicConfig(format='%(message)s')
logger = logging.getLogger()

logger.error(json.dumps({
    'level': 'error',
    'message': 'Database connection failed',
    'error': str(e),
    'timestamp': datetime.utcnow().isoformat(),
    'user_id': user_id
}))

Supported Log Levels:

  • debug - Detailed diagnostic information
  • info - General informational messages
  • warn - Warning messages (potential issues)
  • error - Error messages (failures)

Benefits:

  • All JSON fields are searchable in Railway dashboard
  • Better filtering and analysis
  • Integration with log aggregation tools

Operation 4: View HTTP Logs

Analyze HTTP request patterns and debug API issues.

Dashboard Access:

  1. Railway Dashboard → Service → Observability
  2. Click HTTP tab
  3. View request metadata

Available Metadata:

  • HTTP method (GET, POST, etc.)
  • Request path
  • Status code
  • Response time (ms)
  • Client IP address
  • User agent
  • Timestamp

Filtering HTTP Logs:

# Filter by status code
@httpStatus:500

# Filter by path
@path:"/api/users"

# Combine filters
@httpStatus:500 AND @path:"/api"

Use Cases:

  • Identify slow endpoints (high response time)
  • Find error patterns (500, 404 status codes)
  • Analyze traffic patterns
  • Debug API issues
  • Monitor rate limits

Performance Analysis:

# Find slow requests (>1000ms)
# Filter in dashboard: responseTime > 1000

# Find all 5xx errors
# Filter: @httpStatus:5xx

# Analyze specific endpoint
# Filter: @path:"/api/checkout"

Operation 5: Filter and Search Logs

Use Railway's powerful filtering syntax for targeted log analysis.

Filter Syntax:

Filter Example Description
Substring "error" Search for text
HTTP Status @httpStatus:500 Filter by status code
Service ID @service:<id> Filter by service
Log Level @level:error Filter by severity
Custom Field @userId:123 Filter by JSON field

Boolean Operators:

# AND - Both conditions must match
@httpStatus:500 AND @path:"/api"

# OR - Either condition matches
@level:error OR @level:warn

# NOT - Exclude matches
NOT @path:"/health"

# Grouping
(@level:error OR @level:warn) AND @service:api

Common Filter Patterns:

# All errors from last hour
@level:error

# Slow HTTP requests (>1000ms)
@httpStatus:200 AND responseTime > 1000

# Failed API calls
@path:"/api" AND @httpStatus:5xx

# Exclude health checks
NOT @path:"/health" NOT @path:"/metrics"

# Specific user errors
@level:error AND @userId:12345

# Database connection issues
"connection refused" OR "timeout"

Dashboard Filtering:

  1. Observability → Logs
  2. Enter filter in search box
  3. Use dropdowns for common filters
  4. Save frequent filters as presets

CLI Filtering:

# Use grep for basic filtering (streaming is default)
railway logs | grep ERROR

# Use jq for JSON logs
railway logs --json | jq 'select(.level == "error")'

# Complex filtering with awk
railway logs | awk '/ERROR/ || /WARN/'

Operation 6: Export Logs Externally

Export logs to external systems for long-term retention and analysis.

Why Export?

  • Railway retention: 7-30 days (plan dependent)
  • Long-term log storage
  • Advanced analytics
  • Compliance requirements
  • Centralized multi-service logging

External Export Options:

Option 1: Locomotive Sidecar (Webhook Export)

Deploy a sidecar container to forward logs via webhooks.

Repository: https://github.com/railwayapp/locomotive

Setup:

# Add locomotive service to Railway project
railway service create locomotive

# Configure environment variables
WEBHOOK_URL=https://your-log-endpoint.com/ingest
WEBHOOK_METHOD=POST
WEBHOOK_HEADERS='{"Authorization": "Bearer xxx"}'

# Deploy locomotive
railway up

Supported Destinations:

  • Custom webhooks
  • Datadog
  • Axiom
  • BetterStack
  • Logtail
  • Any HTTP endpoint

Option 2: OpenTelemetry (OTEL) Integration

Send logs using OTEL protocol.

Environment Variables:

# Add to your service
OTEL_EXPORTER_OTLP_ENDPOINT=https://otel-collector.example.com:4318
OTEL_EXPORTER_OTLP_HEADERS=x-api-key=xxx
OTEL_SERVICE_NAME=my-railway-service

Supported OTEL Collectors:

  • Grafana Alloy
  • OpenTelemetry Collector
  • Datadog Agent
  • New Relic
  • Honeycomb

See Also: observability-stack-setup for LGTM stack

Option 3: Log Streaming Script

Use the provided script to stream logs to external systems.

Usage:

# Stream to file
.claude/skills/railway-logs/scripts/stream-logs.sh --output file --path logs/

# Stream to webhook
.claude/skills/railway-logs/scripts/stream-logs.sh --output webhook \
  --url https://logs.example.com/ingest \
  --token YOUR_API_KEY

# Stream to S3
.claude/skills/railway-logs/scripts/stream-logs.sh --output s3 \
  --bucket my-logs-bucket \
  --prefix railway/

Features:

  • Continuous streaming
  • Automatic reconnection
  • Buffering and batching
  • Multiple output formats

Option 4: Manual Export

Export logs for ad-hoc analysis.

# Export last 1000 lines
railway logs --lines 1000 > logs-$(date +%Y%m%d-%H%M%S).txt

# Export recent logs (specify number of lines)
railway logs --lines 1000 > logs-recent.txt

# Export and compress
railway logs --lines 5000 | gzip > logs.txt.gz

Scheduled Export (cron):

# Add to crontab (every 6 hours)
0 */6 * * * railway logs --lines 10000 > /backup/railway-logs-$(date +\%Y\%m\%d-\%H\%M).txt

Integration with External Tools

Datadog

# Install Datadog agent in Railway
# Add environment variables:
DD_API_KEY=xxx
DD_SITE=datadoghq.com
DD_LOGS_ENABLED=true
DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true

Axiom

# Use locomotive sidecar
WEBHOOK_URL=https://api.axiom.co/v1/datasets/<dataset>/ingest
WEBHOOK_HEADERS='{"Authorization": "Bearer <token>"}'

BetterStack (Logtail)

# Add to your application
LOGTAIL_SOURCE_TOKEN=xxx

# Use Logtail SDK
npm install @logtail/node

Grafana Loki

# Deploy Grafana Agent/Alloy
# Configure to scrape Railway logs
# See observability-stack-setup skill

Best Practices

1. Structured Logging

DO:

console.log(JSON.stringify({ level: 'info', message: 'User login', userId: 123 }));

DON'T:

console.log(`User ${userId} logged in`); // Hard to search/filter

2. Log Levels

Use appropriate severity:

  • debug - Development/troubleshooting only
  • info - Normal operations
  • warn - Potential issues (high memory, slow queries)
  • error - Failures requiring attention

3. Sensitive Data

NEVER log:

  • Passwords
  • API keys
  • Credit card numbers
  • Personal identifiable information (PII)

Redact sensitive data:

console.log(JSON.stringify({
  level: 'info',
  message: 'User login',
  email: 'u***@example.com', // Redacted
  ip: req.ip
}));

4. Performance

Avoid excessive logging:

// BAD - Logs every request
app.use((req, res, next) => {
  console.log(`Request: ${req.method} ${req.path}`);
  next();
});

// GOOD - Log only errors or important events
app.use((req, res, next) => {
  if (res.statusCode >= 400) {
    console.log(JSON.stringify({ level: 'error', method: req.method, path: req.path, status: res.statusCode }));
  }
  next();
});

5. External Export

For production:

  • Export logs to external system (Railway retention is limited)
  • Use structured logging (JSON)
  • Implement log rotation
  • Set up alerts on error patterns

Troubleshooting Common Issues

Issue Solution
Logs not appearing Check application is writing to stdout/stderr
JSON logs not parsing Ensure JSON is on single line (no newlines)
Logs truncated Railway may truncate very long log lines (>10KB)
Missing logs Check log retention period for your plan
Can't filter by custom field Verify field is in structured JSON log
High log volume Reduce logging verbosity, sample logs

Quick Reference

Task Command
Stream runtime logs railway logs
Last N lines railway logs --lines 100
Build logs railway logs --build
Deploy logs railway logs --deployment
Export to file railway logs --lines 500 > output.txt
Filter errors railway logs \| grep ERROR
JSON filtering railway logs --json \| jq 'select(.level == "error")'

Important: CLI vs API

Use CLI for logs, not API. The Railway GraphQL API log queries (deploymentLogs, buildLogs) often return "Problem processing request". The CLI provides reliable log access:

railway logs                    # Runtime logs
railway logs --deployment       # Build/deploy logs
railway logs --lines 100        # Historical logs

See railway-api/references/api-limitations.md for details.


Related Skills


References

See the references/ directory for detailed guides:

Scripts

See the scripts/ directory for automation tools:


Last Updated: 2025-11-26