Is there a fast approximate count for a huge table?
For monitoring, read reltuples from pg_class, which the planner keeps roughly current. It is off by a few percent between vacuums, which is fine for a dashboard and wrong for invoicing.
The index exists but EXPLAIN shows a sequential scan.
Usually one of three things: the query returns a large fraction of the table so the scan really is cheaper, the types do not match so the index is not applicable, or statistics are stale. ANALYZE the table first, then compare with SET enable_seqscan = off to see what the planner thinks the index would cost.
What would you skip entirely?
The reporting layer, until something forces it. It is the part that feels productive to build and the part nobody opens twice.