What to Actually Monitor in a Production Web App

Most teams confuse uptime monitoring with security monitoring. Pingdom telling you the homepage returns 200 doesn't mean your TLS certificate isn't about to expire, your CSP isn't silently broken, or someone hasn't added a sketchy script tag to your checkout page. Real security monitoring for web applications means watching the surface area attackers actually probe — and getting alerted before users (or auditors) find the problem first.

Here's a practical breakdown of what to monitor, how often, and what each signal is actually telling you.

The Layers That Need Eyes On Them

A web application isn't one thing. It's a stack of independently failing systems, and each one needs its own monitoring discipline.

1. TLS and Certificate Health

Certificate expiry is still one of the top causes of production outages. Let's Encrypt's 90-day renewal cycle helps automate this, but automation fails silently more often than people admit.

• Expiry date — alert at 30, 14, and 3 days remaining
• Chain validity — an intermediate cert missing on one server in a load balancer pool will only fail for some users
• Protocol versions — TLS 1.0 and 1.1 should be off; TLS 1.2 minimum, 1.3 preferred
• Cipher suites — no RC4, no 3DES, no CBC modes where avoidable
• HSTS header — present, with a long max-age and ideally includeSubDomains

Run a TLS check from at least two geographic regions. CDN misconfigurations often only show up on specific edge nodes.

2. Security Headers

Headers are configuration, and configuration drifts. Every deploy is a chance for someone to remove a header without realising what it did.

The non-negotiable set:

• Strict-Transport-Security
• Content-Security-Policy (or Content-Security-Policy-Report-Only while you're tuning)
• X-Content-Type-Options: nosniff
• Referrer-Policy
• Permissions-Policy (formerly Feature-Policy)

Monitor these on every deploy, not weekly. A header that disappears after a Friday deploy is a problem you want to know about Friday, not Monday.

3. Content Security Policy Violations

If you have a CSP, you need a report-uri or report-to endpoint collecting violations. Without it, you're flying blind. With it, you'll see:

• Third-party scripts that change their behaviour (analytics vendors love doing this)
• Browser extensions injecting into your pages (mostly noise, but useful baseline)
• Actual XSS attempts hitting your app

Aggregate reports and alert on spikes or new violation sources. A sudden flood of script-src violations from a domain you don't recognise is worth investigating immediately.

4. DNS and Domain Hygiene

DNS is the part of your stack you most often forget exists until it breaks. Track:

• SPF, DKIM, DMARC — phishing protection for your domain
• CAA records — restricts which CAs can issue certs for your domain
• Dangling CNAMEs — subdomains pointing at decommissioned cloud resources are subdomain takeover targets
• Registrar lock and transfer status

5. Cookies and Session Handling

Audit cookies on critical paths — login, checkout, account settings. Flag any cookie that's missing:

• Secure
• HttpOnly (for session cookies)
• SameSite=Lax or Strict

A single third-party widget can add a cookie that violates your own policies. Tag managers are especially good at this.

How Often to Check What

Not everything needs real-time monitoring. Match frequency to the risk profile:

1. Continuous (every minute): uptime, TLS handshake success, response codes on critical endpoints
2. Hourly: CSP violation aggregation, anomalous request rates, WAF blocks
3. Daily: certificate expiry windows, header presence, cookie flags on key flows
4. Weekly: full external surface scan — DNS records, exposed services, mixed content, third-party script inventory
5. Per deploy: security headers, CSP integrity, redirect chains

This is roughly the cadence we built WebSentry around — daily external checks with on-demand scans for deploy verification.

Signals That Indicate Real Trouble

Volume of alerts isn't useful. These are the patterns that actually correlate with incidents:

Sudden Header or Cookie Changes

If Set-Cookie on your login endpoint suddenly stops including HttpOnly, something in your stack changed. Maybe a framework upgrade, maybe a config rollback, maybe something worse. Either way, you want to know within minutes.

New Third-Party Hosts

Keep a baseline of every domain your pages load resources from. A new domain appearing — especially one loading JavaScript — is either an approved marketing change or a supply-chain compromise. There's no third option.

Certificate Issuance You Didn't Trigger

Monitor Certificate Transparency logs for your domains. crt.sh has a free API. A cert issued for admin.yourapp.com that your team didn't request is a serious signal.

Redirect Chain Changes

If http://yourapp.com stops redirecting to https://, or starts redirecting through an extra hop, that's a misconfiguration or worse. Verify the full chain, not just the final status code.

Building the Monitoring Stack

You don't need a single tool — you need coverage. A reasonable setup for a small to mid-size team:

• Uptime: UptimeRobot, Better Stack, or Pingdom
• External security posture: WebSentry for grading SSL, headers, CSP, DNS, CORS, and cookies with change detection
• CSP reporting: a self-hosted endpoint or a service like Report URI
• CT log monitoring: Cert Spotter or Facebook's CT monitoring
• Runtime / WAF: Cloudflare, AWS WAF, or your reverse proxy's logs piped to something queryable

The trap is treating these as set-and-forget. Schedule a quarterly review where someone actually opens each tool, checks the baselines, and confirms alerts are still routing to a human who will respond.

What to Do With the Alerts

Every alert needs a documented response. "TLS cert expires in 3 days" should not require improvisation. Write runbooks for the predictable ones:

• Certificate renewal failure — who owns it, how to renew manually
• CSP violation spike — how to triage, when to widen the policy vs. investigate
• New third-party host detected — who approves additions, where the allowlist lives
• Security header missing after deploy — rollback criteria, who has authority

Alerts without runbooks become alerts that get ignored. Ignored alerts become incidents.

If you want a quick read on where your app currently stands across these areas, run a free scan at websentry.dev — it'll grade you A through F on SSL, headers, CSP, cookies, DNS and CORS in under a minute, and gives you a baseline to monitor against.