Diagnose and resolve common issues with the SLYD platform, compute instances, and applications.
This troubleshooting guide addresses common issues you might encounter when using SLYD. If you can't find a solution to your problem here, please contact our support team or ask Benson for assistance.
Your instance remains in a "Starting" or "Error" state and fails to become available after several minutes.
Navigate to the instance details page and check the status message for specific error information.
Go to Account → Quotas to ensure you haven't exceeded your instance limit for the region or instance type.
If resources are constrained in your selected region, try deploying the instance in a different region.
Visit status.slyd.cloud to see if there are any ongoing infrastructure issues.
Delete the failed instance and create a new one, potentially with a different image or size.
Check the Events tab in your instance details for specific error codes. Common error codes include:
INSUFFICIENT_CAPACITY: The region doesn't have enough resources availableQUOTA_EXCEEDED: You've reached your account limit for this resource typeIMAGE_CORRUPT: The selected image has issues and can't be deployedHARDWARE_FAILURE: Physical hardware issues in the data centerIf you've tried all the steps above and your instance still fails to start, contact support with the following information:
A running instance unexpectedly stopped, restarted, or is experiencing unexpected reboots.
Review resource usage metrics to identify potential resource exhaustion issues.
Connect to the instance and check system logs for error messages, OOM (Out of Memory) events, or crash reports.
# Check system logs
sudo journalctl -xb -p err
# Check for out of memory events
sudo grep -i "out of memory" /var/log/syslog
# Check kernel logs
sudo dmesg | grep -i error
Check your account billing page to ensure no payment issues or account suspensions.
Ensure your application isn't exceeding the instance's resource limits.
# Check current resource usage
htop
# Check disk space
df -h
# Check for processes consuming excessive resources
ps aux --sort=-%mem | head -10
Configure the operating system to preserve crash dumps for analysis.
The instance Events tab will show restart events and any automated actions taken by the platform. Key files to examine include:
/var/log/syslog: General system logs/var/log/kern.log: Kernel-related messages/var/crash/: System crash dumps (if enabled)~/.pm2/logs/: PM2 process manager logs (if using Node.js)/var/log/nginx/: Nginx web server logsYour instance is operational but experiencing poor performance, high latency, or slow response times.
Use monitoring tools to identify which resources are constrained.
# Check CPU, memory, and process information
htop
# Check disk I/O performance
iostat -x 1
# Check network performance
iftop
Adjust application settings to better utilize available resources.
Identify and optimize or terminate unnecessary processes.
Review and optimize database queries, indexes, and connection pooling.
If the workload consistently exceeds current resources, upgrade to a larger instance size.
SLYD provides several built-in tools to help diagnose performance issues:
Additionally, you can install these common performance analysis tools:
# Install common performance tools
sudo apt update
sudo apt install htop iotop iftop sysstat netdata
"Use the Performance Score feature in your instance dashboard to get an overall health rating and specific recommendations. Scores below 70 indicate potential issues that should be addressed."
"Consider enabling auto-scaling if your workload has variable demand patterns. This allows your resources to adjust automatically based on actual usage."
Unable to connect to an instance via SSH, web interface, or application endpoints.
Ensure the instance is in "Running" state and has passed all health checks.
Navigate to Networking → Tunnels to verify the tunnel is active and properly configured.
Check that your instance's firewall allows traffic on the required ports.
Use the web-based terminal in the SLYD Console to access your instance directly, bypassing external networking.
If you can access the instance but not a specific service, verify the service is running:
# Check listening ports
sudo netstat -tulpn | grep LISTEN
# Check SSH service
sudo systemctl status sshd
# Check web server
sudo systemctl status nginx # or apache2, etc.
If you cannot connect via SSH, try these diagnostic steps:
# Add -v (up to -vvv for maximum verbosity) ssh -v [email protected]
# Verify DNS resolution
nslookup instance-xyz.slyd.dev
# Check connection with specific timeout
nc -zv instance-xyz.slyd.dev 22 -w 5
Instance is experiencing high latency, slow data transfer rates, or intermittent connectivity.
Test network speed and latency from your instance.
# Install network tools
sudo apt install speedtest-cli mtr
# Run speed test
speedtest-cli
# Run traceroute with timing
mtr -rw google.com
Identify processes that might be consuming excessive bandwidth.
# Monitor network usage by process
sudo apt install nethogs
sudo nethogs
For web applications, enable compression and caching.
If latency is consistently high, consider deploying to a region closer to your users.
Compare your network performance against SLYD benchmarks:
| Metric | Expected Range | Poor Performance |
|---|---|---|
| Download Speed | 500-2000 Mbps | < 200 Mbps |
| Upload Speed | 400-1500 Mbps | < 150 Mbps |
| Latency (Same Region) | 1-5 ms | > 10 ms |
| Latency (Cross-Region) | 20-100 ms | > 150 ms |
Unable to deploy an application from the marketplace or custom deployment fails.
Check the deployment logs for specific error messages.
Ensure your instance meets the minimum requirements for the application.
If deploying multiple applications, ensure they don't have conflicting dependencies.
If marketplace deployment fails, try installing the application manually to identify specific issues.
Verify the application is compatible with your instance's operating system and environment.
The instance does not have enough memory to run the application.
Solution: Resize your instance to a larger memory configuration or optimize the application's memory usage.
The application has dependency conflicts with existing software.
Solution: Use container isolation or virtual environments to separate applications with conflicting dependencies.
Network timeout occurred during package download.
Solution: Check network connectivity, try again later, or use a mirror repository if available.
Application starts but crashes or exits unexpectedly during operation.
Review application logs for error messages or exceptions.
# Common log locations
# Web server logs
sudo tail -f /var/log/nginx/error.log
# Application-specific logs
sudo tail -f /var/log/your-application/error.log
# System journal for service errors
sudo journalctl -u your-application-service -f
Check if the application is hitting resource limits before crashing.
Use a process manager to automatically restart crashed applications.
# For Node.js applications
npm install -g pm2
pm2 start app.js --name "myapp" --watch
# For Python applications
pip install supervisor
supervisord -c /etc/supervisor/supervisord.conf
Verify all external services the application depends on are available and responding.
Check for application updates that might address known stability issues.
Enable and analyze core dumps to identify crash causes.
# Enable core dumps
ulimit -c unlimited
echo '/tmp/core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern
# Analyze core dump (example for C/C++ applications)
gdb /path/to/application /tmp/core.applicationname.1234
Use profiling tools to identify performance bottlenecks or memory leaks.
Trace system calls and signals to understand application behavior.
# Trace system calls
strace -f -p [PROCESS_ID]
# Trace only specific calls
strace -e open,read,write -p [PROCESS_ID]
Your bill is higher than expected or contains charges you don't recognize.
Examine your billing statement for a breakdown of charges by resource type and instance.
Inventory all running instances, stored snapshots, and persistent volumes.
Review resource utilization graphs to identify unexpected spikes or continuous high usage.
Set up budget alerts and usage notifications to prevent future surprises.
Rightsize instances, delete unnecessary snapshots, and optimize storage.
"I've analyzed your usage patterns and noticed that you could save approximately 35% by using a scheduled shutdown policy for your development instances during non-working hours (nights and weekends)."
"Consider using resource tagging to track costs by project or department, making it easier to identify where optimization opportunities exist."