See inside your running services

Getting your app online is the part everyone talks about. You push, you wait, you get a URL. It feels great for about five minutes.

Then the real questions start. Is it actually healthy? Why did that page feel slow just now? Am I about to run out of memory? How many connections is my database holding open? For a while, the honest answer on ZevCloud was “open a chat with us and we will look for you.” That is not good enough, so we changed it.

We shipped a set of features that let you see, and reach, your running services directly.

Metrics on every service

Every service now has a Metrics tab. It shows what the service is doing right now, and how that has moved over the last hour, day, or week.

You get CPU as a share of the CPU your plan includes, memory in use against your limit, network traffic in and out, and disk activity alongside how much storage the service’s own files take up. Every number is framed against your plan, so a percentage means something instead of floating in the abstract.

There is also a Metrics page in the sidebar that pulls every service in your team into one view. One glance tells you what is running hot and what is idle.

A database gets one more tile: active connections against your limit. This one has already earned its keep, catching an app that opened connections and never closed them before it exhausted the pool.

An app that builds from a repository shows its build too: the size of the built image, how long the last build took, and a short history of recent build times.

I care about this one personally. I have burned evenings staring at a slow app with no idea whether it was memory, the database, or my own code. Having the numbers in front of you turns guessing into looking.

A real terminal

Not a box that runs one command and prints one line back. A proper interactive shell into your running service. You can move around the filesystem, run a migration, tail a file, check a variable, and generally poke at your app the way you would on your own machine.

It opens straight from the service, behind your team’s permissions, and it behaves the same across your apps, your WordPress sites, and your databases. On a database, the engine’s own client is already there, so you can run a quick query without setting anything up first.

Live logs

Logs stream in as they happen, with a time range to pick from and an auto-scroll that follows the tail so you rarely have to touch it. When something crashes on boot, the reason is usually sitting right there in the output. Now you can read it yourself instead of asking anyone.

Why this matters for how we build

Most of the people we build for are small teams, or one person wearing every hat, keeping a close eye on what they spend. When you are that person, “is my app okay” is not an idle question. It is the difference between finding a problem at 9am on your own terms and finding it because a customer told you.

So none of this sits behind a premium tier. It is available by default, for every running service, on every plan. If your service is up, you can see it and reach it.

Where to find it

Open any service and look for the Metrics, Logs, and Terminal tabs. The team-wide view is Metrics in the sidebar. If you want the detail on what each number means, there is a short metrics guide in the docs.

Go and look at your services. You might learn something about them you did not know.