ChirpStack Health Check: 12 Questions to Ask About Your Deployment

Why a health check?

ChirpStack is easy to install and tends to keep running quietly for a long time. That is exactly the problem: a server that "just works" rarely gets reviewed, and small risks pile up until something breaks at the worst possible moment.

This self-assessment takes about 15 minutes. Answer each question honestly with yes, partly or no. Score 2 points for yes, 1 for partly and 0 for no.

Versions and patching

1) Are you on a current ChirpStack v4 release?

Still on v3, or several v4 releases behind? Each skipped release makes the next upgrade larger and riskier. If you are on v3, read our v3 to v4 migration guide.

2) Are PostgreSQL, Redis, your MQTT broker and the operating system patched?

ChirpStack depends on all of them. An up-to-date ChirpStack on an end-of-life database or OS is still an outdated system.

3) Do you have a tested upgrade procedure?

"Upgrade on production and hope" is not a procedure. You want a staging environment, written steps and a known way back.

Backups and recovery

4) Are PostgreSQL and Redis both backed up automatically?

PostgreSQL holds your configuration and devices; Redis holds device sessions and other live state. Losing either has consequences.

5) When did you last restore a backup — and how long did it take?

A backup you have never restored is a hope, not a plan. If you don't know your restore time, you don't know your recovery time.

6) Are backups stored somewhere other than the ChirpStack server?

If the server, the disk or the cloud account is lost, backups stored on it are lost too.

Security

7) Is your MQTT broker locked down?

Anonymous access, shared credentials or a broker exposed to the internet without TLS are some of the most common findings in ChirpStack audits.

8) Are API keys, admin accounts and secrets under control?

Look for old API keys nobody can explain, admin accounts belonging to people who have left, and default or shared passwords. Rotate and remove what you don't need.

9) Is only what needs to be public actually public?

The web interface, API, database and Redis should not be reachable from the internet unless there is a clear reason. Gateways need their ports; most other things do not.

Monitoring and capacity

10) Would you know about a problem before your customers do?

Check that you are alerted on more than "server down": gateways going offline, uplink volumes dropping, integration errors, disk space and memory growth.

11) Do you know how much headroom you have?

Do you know your current device and message volumes, how they are growing, and at what point CPU, memory, database or Redis will become the bottleneck?

Ownership

12) Is there more than one person who can fix it at 2am?

If your ChirpStack knowledge lives in one person's head, that person is a single point of failure. The same applies if your setup is undocumented.

What your score means

Score	What it means
20–24	A well-run deployment. Keep reviewing it at least once a year.
13–19	Solid foundations with real gaps. Fix the zeros first, starting with backups and security.
0–12	Your network is running on luck. Prioritise a proper review before the next incident.

Whatever your score, the most valuable fixes are usually the "no" answers in backups (questions 4–6) and ownership (question 12). Those are the gaps that turn a small incident into a long outage.

Want a second opinion?

Our ChirpStack health check is a structured review of your deployment — versions, security, backups, performance and capacity — carried out by engineers who run ChirpStack in production every day. You get clear findings and a prioritised fix list, whether you fix them yourself or ask us to help.

Book a ChirpStack health check — it starts with a free 30-minute scoping call.