Metrics To Watch#

Use this after rolling out the Coolify + PostgreSQL deployment.

Goals#

Confirm that:

• api stays stable under browse-heavy traffic
• indexer keeps search current through Tap
• PostgreSQL handles ingest, queue churn, and activity writes without backlog

Coolify Application#

Watch both services for 24 to 48 hours after deploy.

API#

Expected direction:

• lower latency spikes
• stable memory
• flat restart count

Useful checks:

• request latency
• CPU and memory
• /readyz failures
• restart count

Indexer#

Expected direction:

• steady-state load during Tap ingest
• bounded spikes during backfill, enrich, and reindex
• /health stays green outside deploy windows

Useful checks:

• CPU and memory
• restart count
• Tap reconnect frequency
• queue drain time after backfill

PostgreSQL#

Expected direction:

• predictable connection count
• stable write latency during ingest
• no long-lived lock buildup in indexing_jobs
• bounded table growth in jetstream_events and indexing_audit

Useful checks:

• connections
• disk growth
• slow queries
• write latency
• backup duration and restore confidence

Admin Signals#

If admin routes are enabled, compare:

• read_through.pending
• read_through.processing
• read_through.failed
• read_through.dead_letter
• tap.cursor
• jetstream.cursor

Healthy behavior:

• pending stays near zero most of the time
• processing drains after bursts
• failed and dead-letter stay small and explainable

Success Signals#

• /readyz and /health remain consistently green
• search freshness tracks Tap ingest
• backfill and enrich jobs complete without manual cleanup
• PostgreSQL latency stays stable during bootstrap and normal use

Failure Signals#

• queue counts rise and do not drain
• /readyz flips during normal browse traffic
• search misses rise after cutover
• PostgreSQL write latency climbs during normal ingest
• restores or backups are failing or taking too long