4 · Post-deploy monitoring & day-2 (P9)

TL;DR

Objective — watch the live app closely through the first 24–48h with smoke tests, integration checks, performance/security spot-checks, log triage, and recorded baselines — keeping rollback one command away — so issues that only surface under real load are caught before they compound.

User part + done-when

👤 User part — the end-to-end smoke test is browser-driven: registering, logging in, resetting a password, and exercising core features as a real user. An agent can run the curl spot-checks, tail logs, and execute a rollback, but it can’t click through the user-facing flows.

Done when the smoke tests and integrations all pass, performance/security spot-checks are within target, logs are triaged, and 48h baselines are recorded — with a rehearsed rollback ready the whole time.  ·  ⏱ ~24–48 hr (watch)  ·  🔀 mixed (👤 smoke tests, 🤖 curl + logs + rollback).

Background

Some issues only surface under real load, on timezone-bound cron jobs, or after a cache expires. Watch closely through the first two days — and keep rollback one command away the entire time.

Steps

1. Monitor the first 24–48 hours (P9)

Run the post-deploy checks, then keep watching.

The first substep is a browser-driven end-to-end pass.

Who does this

👤 User runs the end-to-end smoke test in a browser — registering, logging in, resetting a password, and exercising core features as a real user.

1. Smoke-test immediately — registration, login, password reset, logout, and core features all work end-to-end.

   • ✅ Every core user flow works end-to-end in the browser.

2. Verify integrations — email delivery, key API routes, payment gateway, and queue workers all process.

   • ✅ Email, key API routes, payments, and queue workers all process.

3. Spot-check performance and security — homepage/login/health response times are within target, .env is unreachable (403/404), HTTPS/HSTS present, and APP_DEBUG=false.

   curl -s -o /dev/null -w "Home: %{time_total}s\n" https://<DOMAIN>
   curl -s -o /dev/null -w "%{http_code}\n" https://<DOMAIN>/.env   # Expected: 403 or 404

   • ✅ Response times are within target and .env returns 403/404.

4. Watch logs and triage. Tail the app log, count errors, and classify anything that appears.

   Severity	Definition	Action
   Critical	Core functionality broken	Hotfix immediately
   High	Major UX impact	Fix within 24–48h
   Medium	Minor bug	Next patch release
   Low	Cosmetic / edge case	Backlog

   • ✅ Logs are tailed and every error is classified and actioned by severity.

5. Record baselines after 48h — error rate (< 0.1%), average response time (< 200ms), uptime (99.9%) — and note lessons learned.

   • ✅ Error rate, response time, and uptime baselines are recorded with lessons learned.

Keep rollback one command away

If a critical issue surfaces, roll back first and diagnose second. The previous release is still on the server, and the tag from P4 lets you redeploy a known-good build.

dep rollback production               # switch the symlink to the previous release (preferred)

# or recover from a specific tag — use the PREVIOUS good version, never the
# just-failed ${VERSION} (redeploying v${VERSION} just ships the broken build again):
LAST_GOOD=$(git tag --sort=-v:refname | grep -v "^v${VERSION}$" | head -1)   # e.g. the prior vX.Y.Z
git checkout -b "rescue-from-${LAST_GOOD}" "${LAST_GOOD}" && dep deploy production --branch="rescue-from-${LAST_GOOD}"

Subsequent deploys

After the first launch, the cycle gets short: prepare the release (P1), push through staging → production, tag, and run an abbreviated P9. No installer, no manual .env, no 777 pass — migrations run automatically and every deploy carries built-in safety checks (pre-symlink smoke test, cache-failure blocking, HTTP health check, and automatic rollback if any check fails).

Aspect	First deploy	Subsequent deploys
Database	Empty — installer creates schema	Exists — migrations update schema
Installer	Required (/install)	Not needed
.env / server dirs	Create manually	Already in place
Permissions hardening (P3)	One-time	Skip

flowchart LR
  subgraph first["First deploy"]
    F1[Empty DB] --> F2[Web installer]
    F2 --> F3[Manual .env + dirs]
    F3 --> F4[Full P9 watch]
  end
  subgraph day2["Subsequent deploys"]
    S1[P1 prepare release] --> S2[staging → production]
    S2 --> S3[Auto migrations]
    S3 --> S4[Abbreviated P9]
  end
  first --> day2

End of the pipeline

You’ve reached the end — the app is live, tagged, and monitored. From here the work is ongoing operations, not a further phase: routine updates, hotfix releases, vendor-version syncs (merging a new vendor release while preserving your customization markers), scheduled backups, and incident response — each one a small replay of P1 → P2 → P4 → P9.

Checklist

Do not mark this step done until every box below is checked.

• 👤 Smoke tests pass — registration, login, password reset, logout, and core features work end-to-end.
• 🔀 Integrations verified — email, key API routes, payment gateway, and queue workers all process.
• 🤖 Perf/security spot-checked — response times within target, .env returns 403/404, HTTPS/HSTS present, APP_DEBUG=false.
• 🤖 Logs triaged — app log tailed, every error classified by severity and actioned.
• 🔀 Baselines recorded — error rate, response time, and uptime captured at 48h with lessons learned.
• 🤖 Rollback rehearsed — dep rollback production (or tag-based redeploy) ready the whole window.

→Playbook complete

Return to the Laravel/CodeCanyon setup-new hub to revisit any phase, or use the subsequent-deploy cycle above as your day-2 runbook.