Logging and monitoring without drowning in noise

Short answer: Log the few signals that explain outages and attacks—HTTP errors, auth failures, deploy events, and backup success—then alert on thresholds, not every line.

NZ SMEs rarely need enterprise SIEMs on day one; they need visibility when the site changes state and retention long enough to investigate yesterday’s spike.

Start with “boring” operational logs

• Uptime checks from two regions if you serve nationwide customers.
• SSL expiry and DNS change alerts—surprisingly common outage causes.
• Backup job success with periodic restore tests.

Security-oriented signals

Spikes in 404s to wp-login.php, sudden admin lockouts, or new geographic clusters in failed logins can precede brute-force success. Pair raw logs with a simple weekly review habit.

Retention and privacy

Keep logs long enough to debug, not forever—align with your privacy notice and reduce personal data in logs where possible (mask IPs if your policy requires it).

Frequently asked questions