When something breaks, the first minutes go to answering "what is actually happening?". A big dashboard with forty panels makes that slow. So I put together three compact Grafana dashboards for Prometheus: PostgreSQL HA Lite for a Patroni cluster, Kafka Lag & Brokers Lite, and Argo CD Apps Lite. For each one, here are the five panels I look at first and what they tell you.

All three are free and published on grafana.com:

Patroni and PostgreSQL (26033)

The first question during a database incident is whether there is exactly one leader. The top row answers it.

  1. Leaders (Patroni). Should be exactly 1. Zero means there is no leader. Two or more means a possible split brain, so stop and investigate instead of restarting services.
  2. Leader lock missing. A value of 1 means the DCS has no leader lock. The cluster can have no writable primary even when all nodes are up.
  3. Timeline changes (24h). A timeline change means a failover or promotion. The panel shows whether one happened in the last day, even if it already finished and the service is back. That often explains write errors the application saw earlier.
  4. Max replication lag. Replication lag reported by postgres_exporter on the replicas. The dashboard turns orange at 10 seconds and red at 60 seconds. A large lag means a replica is behind, and failing over to it can lose the latest data.
  5. Longest open transaction. The longest transaction among non-idle sessions. Orange from 5 minutes, red from 30 minutes. A long transaction holds back vacuum and can slow replicas, so it is a common hidden cause of degradation.

Order matters: check the leader and the lock first, then the timeline, then lag and transactions.

Kafka consumer lag and brokers (26034)

In Kafka, an incident usually looks like "messages are not being processed". The total lag can look fine while a single partition is stuck, so look at the breakdown by partition.

  1. Under-replicated partitions. Partitions with fewer in-sync replicas than replicas. An empty panel means every partition is fully replicated. A non-zero value usually means a broker dropped out or cannot keep up.
  2. Consumer group members. The number of members in each group. Zero members with growing lag means the consumers are down. This is the fastest way to tell "slow" from "dead".
  3. Consumer lag by group. Total lag for the selected groups and topics. On its own it says little, so use it as an entry point, not as the answer.
  4. Lag, top N partitions. The partitions with the highest lag. This is where a stuck partition shows up, even when the total looks small. The Top N value is a dashboard variable you can change.
  5. Messages produced vs consumed (per second). Write and read rates side by side. If production continues and consumption drops to near zero, the group is not working. Note that "consumed" is summed over the selected groups, so with several groups on one topic it can exceed "produced".

Argo CD applications (26035)

During an Argo CD incident the question is different: which applications have drifted from git, and why? The stat panels give the overall picture, and the table below them lists applications that need attention.

  1. Applications needing attention. A table of applications that are OutOfSync, Unknown, or not Healthy. An empty table means everything is synced and healthy.
  2. Sync Unknown. Unknown usually means the comparison failed: a repository, manifest, or cluster access problem. Check here first when an application is stuck and not changing.
  3. Degraded / Missing. Applications whose resources are unhealthy or absent in the cluster. This is real impact on the service, not just drift from git.
  4. Failed syncs (24h). Sync operations in the last day that ended in a phase other than Succeeded.
  5. Failed syncs by application. The same failures, broken down by application over the selected range. This tells you which application is failing, not just that something is failing.

One limitation to know: Argo CD does not export a separate sync-duration metric. The duration panels show reconcile (comparison) time. Per-application reconcile errors are not exported as a metric either, so the Unknown and Degraded/Missing statuses and failed sync phases serve as error signals.

Setup

Import the dashboards from grafana.com by ID or from the JSON file. You need Grafana 10 or newer. No data source is hard-coded: pick your Prometheus at import time through the DS_PROMETHEUS input.

Scrape targets:

  • Patroni: REST API on port 8008, path /metrics, Patroni 2.1 or newer.
  • postgres_exporter: port 9187.
  • kafka_exporter (danielqsj/kafka_exporter): port 9308.
  • Argo CD: application controller on port 8082, plus the repo-server on port 8084 if you want the git request panel.

I have not run these dashboards against a live Grafana instance, so check that the metrics exist in your Prometheus before relying on the panels.

Free alert rules with Telegram routing are here: https://devkit-shop.pages.dev/free/