A card for data it couldn't open yet
I added a card to my hub dashboard. It shows sessions that my bots sent to my apps, broken down by UTM source, using the GA4 Data API. The whole change was 41 added lines in one file, hub.py.
When I deployed it, the card couldn't read anything. I hadn't added the GA4 property ID or the service account credentials yet. The commit message says "pipe deployed first": lay the pipe now, plug in the key later.
That order has a trap. If you don't decide what a card shows when it has no key, it tends to show a blank or a zero. And on a dashboard, zero reads as "the bots sent nobody to the apps."
On your own dashboard, how many cards that currently show zero would let you tell, from the screen alone, whether it's a real zero or a missing connection?
Zero and "unknown" are different values
On a traffic card, zero feeds decisions directly. The channel doesn't work, the bot copy needs rewriting, shut it down: any of those can come from a single zero. If that zero comes from missing credentials, the decision rests on something nobody ever measured.
Throwing an error and breaking the card wasn't a good option either. Being unconfigured was the intended state for now, and there was no reason for it to turn the whole hub red.
So the card needed a third state: not a number, not an error, but "awaiting setup."
What would you do: hold the card until the credentials arrive, or ship it now and define the empty state explicitly?
What I did: an env gate and a fail-closed self-check
I shipped first, and I didn't invent a new pattern. Another card in the hub already worked this way, so I reused its env-gate pattern as is.
The behavior is simple. If both GA4_PROPERTY_ID and the service account credentials are present, the card turns on and calls the GA4 Data API. If either is missing, it doesn't call the API and shows an "awaiting setup" fallback.
I added a self-check on top of that. When nothing is configured, it confirms that the card fails closed. The point is to stop an empty config from putting the card into number mode, where empty would quietly turn into zero.
Looking back, most of the 41 lines went to defining when the card must not draw a number, not to drawing one.
Self-check
- For every dashboard card that depends on an external API, does "no credentials" show up as its own label instead of a zero or a blank?
- Is there a check (self-check or test) proving the card stays out of number mode when its config is empty?
- If your codebase already has a gate like this, did you reuse that pattern instead of writing a new one?
The honest part
The only source for this post is the commit that added the card. It doesn't say whether I added the credentials later, what numbers the card showed once it turned on, or whether bot-to-app UTM traffic was large enough to matter, so I can't tell you any of that. The self-check covers the unconfigured state. This commit alone doesn't tell me whether the card also falls back honestly when credentials are present but lack permission, or when the property ID is wrong. Whether laying the pipe first was the right call is something I can only judge after the key goes in.