We’ve optimized the queries, fixed the browser bottlenecks, and set up a deployment pipeline that fails fast instead of failing in production. The code is live. Now what?
The biggest mistake I see teams make on “day two” is setting up a thirty-panel Grafana dashboard that nobody looks at until a customer complains on Twitter. Monitoring isn’t about collecting data; it’s about surfacing pain.
If you don’t have a dedicated DevOps team, here is the minimal stack that actually works.
1. Uptime is binary: The external ping
Don’t monitor your uptime from the same server that runs your app. If the server loses network, your monitor goes down with it in silence.
Use an external service (UptimeRobot, Pingdom, Oh Dear) to ping your homepage every 60 seconds. But don’t just check for a 200 OK. A database failure will often still return a 200 with a blank page or an error message.
The Fix: Create a dedicated /healthz endpoint that actually runs a lightweight `SELECT 1` against your database and checks your Redis connection, returning a 200 only if the core infrastructure is alive. Point your external ping there.
2. Errors need stack traces, not just log lines
Grep-ing through /var/log/nginx/error.log to figure out why a user couldn’t check out is a miserable way to spend an afternoon.
You need an exception tracker (Sentry, Flare, Bugsnag). When PHP throws a fatal error, these tools capture the exact stack trace, the URL, the user agent, and the state of your variables at the moment of the crash.
The Rule: If an error hits Sentry, it means a user experienced a broken flow. Fix it, or ignore it permanently if it’s a known non-issue (like a bot probing for exploits). Don’t let your error tracker become a noisy inbox you ignore.
3. Performance degradation is a slope, not a cliff
Your site won’t suddenly become slow; it will become slow gradually as tables grow and traffic increases. You don’t need full Application Performance Monitoring (APM) like New Relic on day one, but you do need visibility.
In PHP, using a tool like Laravel Telescope (if you’re on the framework) or simply logging queries that take longer than 100ms to a dedicated slow_query.log will catch 90% of your performance drift.
The 3-Step “Day Two” Checklist
- Do I get an SMS/Slack ping within 2 minutes if the database drops?
- When a user sees a 500 Error, do I have the exact line of code that caused it?
- Are my application logs rotated automatically so they don’t fill the disk and crash the server?
If you can answer yes to those three, you are in the top tier of projects I’ve audited. The rest is just noise.
That concludes the fundamentals series. Going forward, I’ll be diving into specific architecture choices, PHP quirks, and front-end experiments. Welcome to the new site.
— Stella
