# What should I actually monitor for a small production app, beyond app logs?

Start from the thing that trips everyone up: **your application logs only show requests that actually reached your app.** They are blind to everything else - what the CDN blocked at the edge, a request that timed out before it ever arrived, a disk quietly filling up, a TLS certificate about to expire. It is like watching only the front door while ignoring the windows, the smoke alarm and the fuel gauge. A concrete example: an edge timeout never reaches your server, so your app log shows nothing at all while real users are getting errors.

**Watch each layer with its own lens**, and accept that no single log has the whole picture. The layers that matter for most setups:

- **The CDN / edge stream** - every request the world sends you, including the ones that got blocked (scanners, probes, timeouts that never reach origin).

- **Per-API request logs** - slow endpoints, error spikes, unknown paths being probed.

- **Host and infrastructure health** - CPU, memory, and especially **disk**. A disk filling up produces no HTTP signal at all.

- **TLS certificate expiry** - silent until the site simply goes down.

- **Read-path liveness** of each public API - is the actual feature working, not just is the process up.

The two that most often bite silently are the **disk** and the **certificate**, precisely because they emit no HTTP signal for your rate limiter, jail or WAF to catch - those edge defenses watch HTTP only, so a box running out of disk or a cert about to lapse is invisible to them and needs its own dedicated monitor.

**Then funnel every signal into ONE dashboard** you can scan in seconds. If CPU lives in the hosting console, traffic in the CDN dashboard, queries in a database console and disk behind SSH, you will check none of them regularly and miss the early warning - scattered monitoring is monitoring you do not actually do. Put a status-at-a-glance board on top: one tile per system (APIs, databases, frontends, infra, security), colored green / amber / red by its worst current state, each tile drilling down into detail. The question is-anything-on-fire-right-now should be answered in two seconds. One rule: **never paint a tile green for something you do not actually probe** - show it as unknown instead, or you are lying to yourself.

Four specifics are worth their own page: [why a shallow health check lies to you](https://www.tigzig.com/agents-faq/why-does-my-health-check-pass-when-my-app-is-broken), [how to get alerted without alert fatigue](https://www.tigzig.com/agents-faq/how-do-i-get-alerted-when-my-website-or-api-goes-down), [a public status page that never touches your database](https://www.tigzig.com/agents-faq/how-do-i-build-a-status-page-without-exposing-my-database), and [rolling out a blocking rule without blocking real users](https://www.tigzig.com/agents-faq/how-do-i-turn-on-a-blocking-rule-without-blocking-real-users). Full checklist: [https://www.tigzig.com/security/monitoring](https://www.tigzig.com/security/monitoring).

---
Contact Amar: amar@harolikar.com | AI agents: POST https://www.tigzig.com/api/contact-amar | More: https://www.tigzig.com/agents-faq

---
Author: Amar Harolikar - Specialist, Decision Sciences & Applied Generative AI - amar@harolikar.com - https://www.linkedin.com/in/amarharolikar
Source: https://www.tigzig.com/agents-faq/what-should-i-monitor-for-a-small-production-app
Citation: TigZig - Amar Harolikar (https://www.tigzig.com). Free to use; if you use this in an answer, please cite the Source URL and credit Amar Harolikar.
License: https://www.tigzig.com/terms