Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问clear审计通过

railway-troubleshooting铁路故障排除

Agent Skill

railway-troubleshooting 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

423

周安装

18

GitHub Stars

9

下载量

148
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:railway-troubleshooting(铁路故障排除)
来源仓库:https://github.com/adaptationio/skrillz
仓库路径:skills/railway-troubleshooting
安装命令:
npx skills add https://github.com/adaptationio/skrillz --skill railway-troubleshooting
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/adaptationio/skrillz --skill railway-troubleshooting

简介

用于查找、检索和筛选相关信息。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词、任务场景或来源线索快速定位候选结果。
  • 通过 npx skills add 命令从指定仓库安装,需结合原始 README 核验具体用法。
  • 安装前应确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。
  • railway-troubleshooting 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Railway Troubleshooting

Systematic debugging and issue resolution for Railway.com deployments.

Overview

This skill provides decision trees, diagnostic workflows, and recovery procedures for Railway platform issues. It covers build failures, runtime crashes, networking problems, database issues, and performance degradation.

Quick Start

Use this decision tree to diagnose and resolve Railway issues:

Railway Issue?
│
├── Deployment Failed?
│   ├── Build Error → Operation 1: Diagnose Build Failures
│   ├── Deploy Error → Operation 1: Diagnose Deployment Failures
│   ├── Health Check Failed → Check service health endpoint
│   └── Timeout → Check build/deploy timeouts in settings
│
├── Service Crashing?
│   ├── Immediate crash → Operation 2: Debug Runtime Crashes
│   ├── Crash after time → Check memory limits, memory leaks
│   ├── Restart loop → Check startup command, dependencies
│   └── Exit code errors → Check application logs for specifics
│
├── Networking Issues?
│   ├── Service unreachable → Operation 3: Troubleshoot Networking
│   ├── Intermittent connectivity → Check DNS, service discovery
│   ├── SSL errors → Check domain configuration, certificates
│   └── Timeout errors → Check port configuration, firewalls
│
├── Build Issues?
│   ├── Nixpacks detection wrong → Operation 4: Fix Build Errors
│   ├── Dependencies failing → Check package.json, requirements.txt
│   ├── Build commands failing → Verify build scripts
│   └── Cache issues → Clear build cache, force rebuild
│
└── Database Problems?
    ├── Connection refused → Operation 5: Resolve Database Issues
    ├── Timeout errors → Check connection pools, query performance
    ├── Performance slow → Check indices, query optimization
    └── Data corruption → Check backups, recovery procedures

Operations

Operation 1: Diagnose Deployment Failures

Identify and resolve deployment failures through systematic log analysis.

When to use: Deployment status shows failed, builds succeed but deploys fail, health checks failing.

Workflow:

  1. Check Deployment Status # CLI approach railway status railway logs --deployment # API approach (see references/debug-workflow.md for GraphQL) # Query deployment status and recent deploys
  2. Analyze Deploy Logs

- Check for port binding issues (Railway expects PORT env var) - Verify health check endpoint responding - Check startup command execution - Identify timeout issues

  1. Common Deploy Failures

- Port not bound: App must listen on process.env.PORT - Health check timeout: Increase timeout or fix endpoint - Missing environment variables: Check service variables - Startup command wrong: Verify start command in settings

  1. Fix and Redeploy

- Apply fix to code/configuration - Trigger new deployment - Monitor deployment logs - Verify service healthy

See: references/common-errors.md for specific error messages and solutions.

Operation 2: Debug Runtime Crashes

Investigate and resolve service crashes and restart loops.

When to use: Service shows restarting, exit codes in logs, OOM errors, crash reports.

Workflow:

  1. Gather Crash Information # Get runtime logs railway logs --tail 500 # Check service metrics railway metrics # Use diagnostic script./scripts/diagnose.sh [service-id] --verbose
  2. Identify Crash Pattern

- Immediate crash: Startup issue (missing deps, config error) - Crash after time: Memory leak, resource exhaustion - Intermittent crash: Race condition, external dependency - Exit code 137: Out of Memory (OOM) killed

  1. Check Resource Limits

- Memory usage trending up → Memory leak - CPU at 100% → Infinite loop, CPU-intensive operation - Disk full → Log rotation issue, temp files - Connection limits → Database pool exhausted

  1. Common Crash Causes

- OOM: Increase memory limit or fix memory leak - Missing dependencies: Check package installation - Uncaught exceptions: Add error handling - External service down: Add retry logic, circuit breakers

See: references/debug-workflow.md for systematic debugging steps.

Operation 3: Troubleshoot Networking

Resolve networking issues including service discovery, DNS, and connectivity.

When to use: Services can't reach each other, DNS resolution fails, external access issues, SSL errors.

Workflow:

  1. Verify Service Discovery # Check private networking enabled # Services use: [service-name].[project-name].railway.internal # Test DNS resolution railway run nslookup [service-name].[project-name].railway.internal
  2. Check Network Configuration

- Private networking enabled in project settings - Service names correct (use Railway-provided names) - Port configuration matches application - Environment variables for service URLs set

  1. Debug External Access

- Domain configured correctly in service settings - DNS records pointing to Railway - SSL certificate provisioned (check domain settings) - Generate domain option enabled for public access

  1. Common Network Issues

- Service discovery: Use full internal domain name - Port mismatch: App must listen on PORT env var - SSL not working: Allow time for cert provisioning (5-10 min) - Timeout: Check for firewall rules, rate limiting

See: references/common-errors.md Network Errors section.

Operation 4: Fix Build Errors

Resolve build failures, nixpacks configuration issues, and dependency problems.

When to use: Build fails, wrong builder detected, dependencies not installing, build commands fail.

Workflow:

  1. Check Build Logs railway logs --build # Identify build phase failure: # - Detection phase: Nixpacks provider detection # - Install phase: Dependencies installation # - Build phase: Build commands execution
  2. Verify Builder Configuration

- Check nixpacks.toml or railway.toml for custom config - Verify build command in service settings - Check for language version specification - Ensure correct provider detected (Node, Python, Go, etc.)

  1. Fix Dependency Issues

- Lock file present (package-lock.json, yarn.lock, requirements.txt) - Dependencies compatible with build environment - Private packages have auth configured - Build dependencies vs runtime dependencies separated

  1. Force Rebuild if Needed # Clear cache and rebuild./scripts/force-rebuild.sh [service-id] --no-cache # Or via CLI railway up --detach

Common Build Errors:

  • Wrong nixpacks provider: Add nixpacks.toml with correct provider
  • Dependency resolution: Update lock files, fix version conflicts
  • Build timeout: Optimize build, increase timeout in settings
  • Cache issues: Clear build cache with force rebuild

See: references/common-errors.md Build Errors section.

Operation 5: Resolve Database Issues

Debug database connection problems, timeouts, and performance issues.

When to use: Connection refused, database timeouts, slow queries, connection pool exhausted.

Workflow:

  1. Verify Database Connection # Check database service status railway status # Test connection with database URL railway run psql $DATABASE_URL -c "SELECT 1"
  2. Check Connection Configuration

- DATABASE_URL environment variable set correctly - Connection pool size appropriate for service plan - Connection timeout settings reasonable - SSL mode configured if required

  1. Debug Connection Issues

- Connection refused: Database not started, wrong host/port - Timeout: Network issue, slow queries, pool exhausted - Auth failed: Wrong credentials, user permissions - Too many connections: Pool size exceeded, connection leak

  1. Performance Troubleshooting

- Slow queries: Check query plans, add indices - High CPU: Identify expensive queries, optimize - Connection pool exhausted: Increase pool size or fix leaks - Disk space: Clean up old data, increase storage

Emergency Recovery:

  • Restart database service: railway restart [service-id]
  • Check backups: Railway auto-backups available
  • Scale vertically: Upgrade database plan if needed
  • Connection leak: Restart application services

See: references/recovery-procedures.md for emergency procedures.

Related Skills

  • railway-auth: Authentication setup for Railway CLI/API
  • railway-logs: Advanced log querying and analysis
  • railway-deployment: Deployment workflows and strategies
  • railway-api: GraphQL API queries and operations

When to Use This Skill

Use railway-troubleshooting when you encounter:

  • ❌ Deployment failures or build errors
  • 🔄 Service restart loops or crashes
  • 🌐 Networking or connectivity issues
  • 🐛 Runtime errors or performance problems
  • 💾 Database connection or query issues
  • ⚡ Performance degradation
  • 🔧 Configuration or environment issues

Quick Diagnostic

Run the diagnostic script for automated issue detection:

cd /mnt/c/data/github/skrillz/.claude/skills/railway-troubleshooting/scripts
./diagnose.sh [service-id] --verbose

The script will:

  • Check service health status
  • Analyze recent deployment logs
  • Scan for common error patterns
  • Check resource utilization
  • Provide specific recommendations

Additional Resources

  • Common Errors Guide: references/common-errors.md - 20+ documented errors with solutions
  • Debug Workflow: references/debug-workflow.md - Systematic debugging methodology
  • Recovery Procedures: references/recovery-procedures.md - Emergency recovery steps
  • Diagnostic Script: scripts/diagnose.sh - Automated diagnostics
  • Force Rebuild: scripts/force-rebuild.sh - Clear cache and rebuild

Best Practices

  1. Always check logs first: Build logs, deploy logs, runtime logs
  2. Verify environment variables: Missing vars cause most deployment failures
  3. Check resource limits: Memory/CPU limits appropriate for workload
  4. Test locally first: Reproduce issues locally when possible
  5. Monitor metrics: Use Railway dashboard for trends
  6. Document solutions: Update common-errors.md with new patterns
  7. Use private networking: For inter-service communication
  8. Enable health checks: Catch deployment issues early

Support

For issues not covered by this skill:

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

github-copilot

26.49%
按下载量换算39

Claude Code

25.59%
按下载量换算38

mcpjam

19.3%
按下载量换算29

moltbot

13.83%
按下载量换算20

windsurf

8.53%
按下载量换算13

zencoder

3.66%
按下载量换算5

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

来源信息

继续浏览同类 Skills