Troubleshooting

Logs and monitoring

Knowing what your resources are doing, and what changed and when, is the difference between a quick fix and a guess. Server and application logs Your own logs live inside your servers: the operating system logs and your application's logs. Connect over SSH (how to connect) to read them. For anything important, ship these somewhere off the server so you still have them if the server fails. Platform metrics The console shows health and basic metrics for your resources, so you can spot a server that is constantly maxed out (a sign to resize) or a disk filling up. Account activity Actions taken in your account are recorded, which matters for security and for working out what changed before a problem. If you run a team, pair this with least-privilege roles and review access from time to time. For deeper, programmatic metrics, the platform exposes monitoring through its API; see the developer documentation.

Cannot sign in to the console

If you cannot get into the console at platform.gewape.cloud, work through these in order. 1. Check the basics. Confirm you are on platform.gewape.cloud and using your Gewape ID email and password. A caps-lock or a saved old password is the most common cause. 2. Forgotten password. Use the Forgot password link on the sign-in page to reset it by email. 3. Two-factor code not working. The 6-digit code is time-based, so the clock on your phone must be correct. If your phone time is off, enable automatic time in its settings. If you have lost the authenticator entirely, follow How to reset your authenticator (2FA) app. 4. Account or access. If your password and code are right but you still cannot get in, your access may have been changed by an administrator on your account. Ask them to check your membership and role (see Team members and roles). Still stuck after these, contact support and say exactly which step fails and any error message you see.

My server is slow

When a server feels slow, the goal is to find which resource is the bottleneck: CPU, memory, disk, or network. 1. Log in and look. Connect over SSH (how to connect) and check usage. On Linux, top or htop shows CPU and memory; df -h shows disk space; iostat shows disk activity. 2. CPU or memory maxed out. If the server is constantly at its limit, it has outgrown its plan. Move it to a larger Server Plan with Resize your server. 3. Disk full or busy. If the disk is nearly full, free space or add a volume. If the disk is the bottleneck under load, a plan with more resources or moving heavy data to a separate volume helps. 4. The application, not the server. Often the server is fine and the app is the issue: a slow database query, a misconfigured web server, or a traffic spike. Check the application's own logs. If the slowness is network reachability rather than the server itself being busy, see My server cannot be reached.

A volume will not attach or mount

Adding a volume has two stages, and problems usually sit in one of them: attaching it to the server, and mounting it inside the server. It will not attach - Confirm the volume and the server are in the same region. A volume can only attach to a server in its own region. - Confirm the volume is available (not already attached to another server). Detach it from the old server first. It attaches but the server does not see it Attaching makes the disk visible to the operating system, but you still have to prepare it once. 1. Log in over SSH and run lsblk to see the new disk (often /dev/vdb or similar). 2. If it is brand new, create a filesystem on it, then mount it to a folder. 3. Add it to /etc/fstab so it mounts automatically after a reboot. A missing fstab entry is the usual reason a mounted volume "disappears" after restarting. Never format a volume that already holds data; formatting erases it. If in doubt, take a snapshot first.

Object storage access errors

If a tool or app gets "access denied" or authentication errors talking to Object Storage, check these. 1. Right keys. Object storage uses S3 access keys, not your console password or an Application Credential. Create a pair with the S3/EC2 credentials option and use the access key and secret exactly, with no extra spaces. 2. Right endpoint. Point your tool at the region's endpoint, for example https://s3.nbo.gewapecloud.com for Nairobi. Using the wrong region's endpoint gives permission or not-found errors. 3. Right bucket and permissions. Confirm the container (bucket) name is correct and that your keys belong to the same project that owns it. To serve a file publicly, the object must be set to public read; otherwise anonymous requests are denied. 4. Path style. Some older S3 tools need "path-style" addressing. If bucket-in-hostname requests fail, switch the tool to path-style. For the developer-level detail and code examples, see the developer documentation at developers.gewape.cloud.

Cannot connect to a managed database

If your application cannot reach a managed database, check from the outside in. 1. Endpoint and port. Use the exact connection endpoint and port shown on the database instance under Databases. A typo here is the most common cause. 2. Firewall. The database sits on your network. The server or app connecting to it must be allowed to reach the database port. Open that port to the app's address in your security rules, and keep it closed to the public internet. 3. User and password. Confirm the database user exists and the password is right, and that the user is allowed to connect from the app's host. 4. Same network. The simplest, safest setup is to keep the app and the database on the same private network so traffic never leaves it. If the instance itself is unhealthy rather than unreachable, check its status under Databases and, if needed, contact support with the instance name and region.