# GPU host reliability in the console: how to read and use it

URL: https://cloudj.net/blog/gpu-host-reliability-score
Published: 2026-11-12 · Updated: 2026-11-12

> Read GPU host reliability in the Cloudj console: the reliability percentage, max duration, Datacenter badge, network speed, the filter, and why to back up.

Every machine in the Cloudj GPU list is a separate, independent host, so two listings for the same GPU model in the same country can behave very differently. The console gives you a handful of signals to judge each one, and the most visible is the reliability percentage. This article explains how to read GPU host reliability alongside the other signals on each row, how to use the minimum reliability filter, and why none of these numbers replaces a backup.

The country and model filters that produce this list are covered in [how to filter GPUs by country](https://cloudj.net/blog/filter-gpu-by-country-console).

## The signals on each row

Each result in the GPU deploy page shows, among other things:

| Signal | What it tells you |
|---|---|
| **Reliability** | A percentage for that host. Treat it as a relative signal: higher is better |
| **Max duration** | How many days the machine is available for. The instance page shows the exact "available until" date |
| **Datacenter** badge | The host is located in a data centre |
| **Download speed** | The host's network speed in Mbps, which affects how fast you pull models and data |
| **Bandwidth price** | Per TB down and up, charged per GB used |
| **Country** | Where the machine is; country level only |

Before any machine appears in the list at all, it has passed Cloudj's own minimum checks on reliability, network and listing duration. The list you see is already filtered; the signals help you choose among what remains.

## Reading reliability

Reliability is the single quickest way to compare two otherwise similar listings. A few practical rules:

- **Compare, do not obsess.** Between two machines at a similar price, prefer the higher reliability, especially for anything long or user-facing.
- **Weigh it against the job.** A short experiment can tolerate a lower figure; a multi-day training run or a public API cannot.
- **Do not read it as a promise.** A percentage describes a track record, not a guarantee. The console states it plainly: machines are independent hosts with no hardware SLA.

## Max duration and the end date

Max duration is easy to overlook and often more important than reliability. Each machine is available until a certain date; when that date arrives, the instance and its disk are removed. For any job, check:

1. Your estimated run time, with margin.
2. The machine's end date.
3. That the second is comfortably later than the first.

If no machine lasts long enough, split the job into stages with checkpoints, so each stage fits on whatever machine is available.

## The Datacenter badge

The badge marks hosts that sit in a data centre, and a **Datacenter only** switch filters to them. Data-centre hosts typically have more consistent power and networking, which is why many teams prefer them for services and long runs. Machines without the badge can still be excellent, often with competitive prices, and are perfectly reasonable for experiments and batch work. The [datacenter vs independent GPU hosts](https://cloudj.net/blog/datacenter-vs-independent-gpu-hosts) article goes deeper into this trade-off.

Note that turning on "Datacenter only" shortens the list, sometimes to nothing in a given country. Try your search with and without it.

## Network speed

The listed download speed matters most when you pull large models or datasets onto the host, or when you serve heavy traffic. For an LLM service, a slow host connection adds to every response. For training on a dataset you download once, it matters only at the start. You can set a minimum download speed in the filters if your job depends on it.

## Using the minimum reliability filter

The filters include a **minimum reliability** setting. A sensible approach by job type:

| Job | Minimum reliability | Datacenter only | Notes |
|---|---|---|---|
| Quick experiment, notebook session | Leave default | Off | Lowest price usually wins |
| Batch job of a few hours | Moderate | Optional | Save outputs as you go |
| Multi-day training | High | Consider on | Checkpoints off the instance |
| Public API or voice service | High | Consider on | VPS front end, redeploy script ready |

If a high minimum returns nothing, lower it a step, widen your country list, or accept a different model. Stock changes during the day; check the console again later. Live "from" prices per model are on [GPU cloud](https://cloudj.net/gpu-cloud).

## Why you still need backups

Even the most reliable listing can go offline. When a host goes offline, billing for that instance pauses, but there is no automatic move to another machine, and your disk stays on that host. Plan for it:

- Copy checkpoints and outputs off the instance regularly, not only at the end. The [backup before a machine's end date](https://cloudj.net/blog/backup-gpu-instance-before-contract-ends) article shows how.
- Keep your environment in a setup script or a custom image, so a replacement machine is ready in minutes.
- For services, put a VPS in front of the GPU so you can point it at a new host without changing your public address.

## Watching the instance once it runs

After deploying, the instance page shows status, GPU utilisation and the last lines of the container logs. Inside the instance, `nvidia-smi` and standard Linux tools tell you more. The [monitor VPS resources](https://cloudj.net/blog/monitor-vps-resources) article covers tools such as `htop`, `df` and simple alerting that apply equally to a GPU instance.

## FAQ

### Does a high reliability percentage guarantee uninterrupted service?

No. It is a signal from the host's track record. Machines have no hardware SLA, so keep backups.

### What happens to my bill if the host goes offline?

Billing pauses while it is offline. There is no automatic move, so you may need to deploy a new instance.

### Should I always turn on "Datacenter only"?

Not always. It suits long runs and services. For experiments, machines without the badge are often a good choice.

### Why does no machine pass my minimum reliability?

The list changes during the day. Lower the minimum slightly, add more country codes or try another model.

## Choose your next machine carefully

Open the [deploy page](https://app.cloudj.net/deploy/gpu), set a minimum reliability that suits your job, and compare end dates as well as prices. Live prices are on [GPU cloud](https://cloudj.net/gpu-cloud).