The source data api sometimes returns valid responses with only a (random?) subset of available reporting utilities. Since the server currently replaces the entire previous table with the most recent data, these responses lead to a mismatch between available utilities and measured reports which manifest as runtime exceptions in the front-end. Bad UX.

There's a temporary fix to simply not update the reporting db table if the source data is a subset of available utilities. This leads to a degraded experience since the available data will then be much further out of date (though without crashing).

A better outcome would be to switch from using full table replacements to incremental updates of the data returned from the source API.

It'd be nice if this app didn't require a hand-rolled VPS setup.

When the source data api returns a partial update, the data is currently cached but not used to update the DB. This situation is logged server-side, but since the end-user experience is only an extra delayed chart/table update, it would be nice if this state was exposed via API such that some sort of indicator could then be added to the front-end.

Create an override and tests to verify the status=500 code paths where the connection is invalid.

The state dashboard has color-coded indicators of the trends (increasing, constant, decreasing) in wastewater reports per utility. This would be a nice feature to surface in the API.

The state dashboard displays reported case counts next to wastewater measurements. It would be nice to also surface this data.

Build on #7 to surface via API the utilities with the largest recent changes. Experiment with absolute and relative changes to see what is most useful.