Forum

Hello, I have checked the three servers under your account:

1. Tencent Shanghai 2C/4G (Initialized today at 10:24) — K3s service is active and running, Node is Ready, all kube-system pods are Running, memory usage is 1.0 / 3.6 GiB, and the server itself is not offline.
2. Aliyun Shanghai 2C/4G (Purchased on 5/1) — K3s has been running continuously for 4 days and 12 hours without interruption, all pods are normal, and the server itself is not offline.

In other words, for the two "K3s offline" cards in your screenshot, the K3s service inside the servers is healthy. The status on the Dashboard reflects the last time the Zeabur monitoring agent attempted to poll the server's K3s API—network conditions in mainland China can occasionally cause this monitoring link to timeout briefly, but this does not mean the server itself has crashed, nor will your deployed services be interrupted.

3. The Aliyun ECS you connected yourself (叙源-ECS) — This server is experiencing multiple banner timeouts via external SSH. TCP port 22 is open, but the SSH handshake hangs, which is usually caused by high CPU/memory usage or sshd throttling. I recommend using VNC / Workbench from the Aliyun console to check top, free -h, and systemctl status k3s. Your only currently running service, soloent-web-cn, is on this machine, and the frequent K3s disconnections are likely originating from here.

Regarding "whether it is suitable for production deployment": Many users already use Zeabur in production environments. In dedicated server mode, K3s is installed within your own instance, so the stability limit depends on the cloud provider's instance stability. The two servers purchased via Zeabur are healthy at the infrastructure level; it is actually the ECS you connected yourself that has real issues. You can start troubleshooting from that machine.

If it's convenient, please post the CPU/memory usage seen in the Aliyun console, or the top results from that ECS, and I can help you further identify the root cause.

Thanks for the reply, I'll take a look. Also, I requested a refund for the Aliyun Shanghai 2C/4G instance, and I can no longer see that machine on my end.

Just passing by to give some support. I currently have four production services running on Zeabur, and the only issues I've encountered are due to my own poor coding; I've had almost no issues on Zeabur's end so far. 👍

@程序猿DD Regarding the "Tencent server that occasionally turns red and self-heals during the day"—your assessment is correct. I just checked the monitoring data for this Tencent Shanghai server over the past 24 hours: regarding the scrape link from the Zeabur monitoring side to the server, there were indeed two instances today (at 14:13 and 19:38) where a single poll failed and recovered in the next cycle. The server's internal nodes remained Ready throughout and did not actually go down.

The mechanism is as follows:

• The server status displayed on the Dashboard is based on the response time obtained by the Zeabur overseas monitoring cluster periodically hitting the server's K3s API (6443) and metrics endpoints. The path is "Zeabur Monitoring (Overseas) → Cross-border Public Network → Server".
• Cross-border network issues between mainland China and overseas, such as carrier egress or submarine cable jitter, can cause a single probe to time out, but it will connect again on the next attempt. This is why you see the "Red → Self-healing" phenomenon.
• This link is only used for monitoring and "dashboard → server" deployment/control commands. User traffic accessing your service goes directly to the server's own public IP and does not pass through this Zeabur monitoring hop. Therefore, a brief red flash on the Dashboard does not mean the service is unavailable to the public—if you curl your service's domain during those few minutes of red, it should remain accessible.

In short, you can treat these brief red flashes as visual noise on the dashboard; they do not affect production traffic. If it ever stays red for more than a few minutes without self-healing, or if you find that your external service is truly unreachable, please post the server ID and I will take a look for you.

Yes, you understood it perfectly 👍 The traffic light is just an instantaneous status on the dashboard display layer; as long as your deployed service is running stably, that's what matters. We will close this ticket for now, but feel free to open a new one if you have any other questions later 🙏