Weekly screen uptime from connection events

A Go Cloud Function that reconstructs a weekly connection score for every screen from sparse connect and disconnect events.

My role: Sole author. I wrote 17 of 18 commits and had it ready for production in under a week.

September 2025

• Go
• GCP Cloud Functions
• PostgreSQL

Reconstructing uptime

The operations team needed one score per screen per week to know which devices had unreliable connections. This makes it possible to check the worst screens before a customer needs to report them.

The platform does not directly record uptime. It only stores connection and disconnection events with timestamps, so the complete week has to be rebuilt from these state changes. A screen that stays connected for the whole week can produce no event at all, which is where most of the edge cases come from.

What I built

I wrote a Go Cloud Function that reads the fleet and event history from two PostgreSQL databases, computes the weekly score for every screen, then writes the results back for the maintenance dashboard.

Two rules handle most of the difficult cases.

The state before the week is the opposite of the first event inside it. If the first event is a disconnection, the screen must have been online until that moment. If it is a connection, it was offline before. This gives me the state from Monday morning until the first recorded change.

No event does not mean no data. If the screen never changes state during the week, its last known state continues for the complete period. Without this fallback, a screen that stayed online and one that stayed offline would both look empty.

Fixing the query shape

My first version queried the database once per screen. It worked during local testing, but for a fleet of several thousand screens it meant several thousand round trips inside a function billed by execution time.

I replaced it with two batched queries using pq.Array and one batch UPDATE for the results. The number of database requests is now fixed even when the fleet grows, and the score slices are preallocated for 4,096 units.

Debugging a scheduled function

A scheduled cloud function only gives you the information you decided to log before running it. I added structured logs throughout the process, a DEBUG mode that limits a run to a small number of screens so I can verify the arithmetic by hand, and a 500-row limit on the generated histograms.

In numbers

I wrote 17 of 18 commits and had the function ready for production in under a week. Each run uses two batched queries and one batch UPDATE across two databases, for a fleet of several thousand screens.