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.

Steps at a glance:

1. Monitor the first 24–48 hours — Run the post-deploy checks, then keep watching.

User part + done-when

🔀 User part — browser smoke tests are agent-driven when automation is available after any required human login/password entry. The human owns account creation, password entry, real reset-link mailbox completion, live payment/email triggers, and launch judgment. The agent drives public auth renders, auth-guard redirects, seeded reset requests, logout after a human login, core-feature sweeps, curl checks, logs, and rollback readiness.

Done when the smoke tests and integrations all pass, performance/security spot-checks are within target (including uploaded/module assets resolving and no raw .php served under /packages), logs are triaged, and 48h baselines are recorded — with a rehearsed rollback ready the whole time.  ·  ⏱ ~24–48 hr (watch)  ·  🔀 mixed (🤖 browser/curl/logs + rollback, 👤 password/account/live-trigger moments).

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. Use the same split as Phase 5: agent-drivable checks are executed, human-only credential/account/payment/email moments are tracked with owner and trigger.

Who does this

🔀 User + Agent — 👤 User performs password entry, real account creation, and live email/payment triggers. 🤖 Agent drives every non-secret browser check after the session exists, including logout and dashboard/core-feature sweeps.

For any provider console follow-up during the watch window — Sentry, MonSpark, Slack/Discord, Stripe, analytics, or Cloudflare — use the vendor console automation guide so the agent can verify non-secret state without handling credentials or live payment/email triggers.

1. Smoke-test immediately — login page render, signup page render, auth guard, seeded reset request, logout after human login, and core features all work end-to-end; human-only registration/password-entry/real-mailbox/payment rows are tracked if not completed during launch.

   • ✅ Every agent-drivable core user flow works end-to-end in the browser, and every human-only remainder has an owner/trigger.

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), uploaded media + module assets resolve, 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
   
   # Assets must resolve — a dead public/storage symlink (vendors often ship it pointing at /var/www/...)
   # or a missing public/packages link 403/404s every uploaded image and in-tree module asset.
   curl -s -o /dev/null -w "logo: %{http_code}\n"  https://<DOMAIN>/storage/<a-known-uploaded-asset>   # Expected: 200
   # In-tree module apps only (e.g. WorkDo /packages/...): if used, a known module asset must also be 200.
   
   # SECURITY: a blanket public/packages symlink can expose raw PHP source — confirm .php under /packages is NOT served.
   curl -s -o /dev/null -w "pkg-php: %{http_code}\n" https://<DOMAIN>/packages/<vendor>/<module>/src/<any>.php  # Expected: 403/404, never 200

   • ✅ Response times are within target, .env returns 403/404, uploaded/module assets return 200, and raw .php under /packages is not served (403/404). If media 404s, the per-env symlink wasn’t recreated on deploy (storage:link / the packages link); if .php is served, restrict /packages to asset extensions or publish module assets instead of symlinking the source tree.

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 the verified non-production target from Zaj-PROJECT.md → release branch (main in setup-new) → production deploy target, 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[non-production → 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.

A vendor-version sync re-introduces an untrusted vendor/ — re-run the seam audit every time

Merging a new vendor release drops a fresh, unverified vendor/ on top of your tree. The exact tampering you stripped in Phase 2 · Extract & snapshot §5 can reappear in the new version — and a CodeCanyon ZIP ships its vendor/ at the locked versions, so a plain composer install is a no-op ("Nothing to install or update") and any tampering persists. After restoring/merging vendor files on a vendor update you must:

1. Re-run the backdoor-signature scan over the diff vs clean upstream (core-package guard for laravel/framework, symfony/*, illuminate/*; signatures: chr(/\xNN blobs, getCourant/HeaderCodec, getScript/eval/gzinflate/base64_decode, vendor phone-home domains like envato./verify.js, login/register route gating).
2. Force-clean tampered packages — composer reinstall <vendor>/<package> (or rm -rf vendor && composer install), never a bare composer install.
3. Grep-verify the signature is gone, then re-apply only the load-bearing functional patches you classified, and re-run the boot-clean-boot route gate (AFTER ≥ BEFORE).

grep -rEl 'getCourant|HeaderCodec|envato\.|verify\.js' vendor/ 2>/dev/null \
  && echo "❌ tampering present after the vendor sync — composer reinstall the flagged packages, do NOT composer install" \
  || echo "✅ vendor/ clean after the sync"
# Expected: "✅ vendor/ clean after the sync"

Checklist

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

• 🔀 Smoke tests pass — agent-drivable auth/render/reset-request/auth-guard/logout/core-feature checks pass; human-only registration/password-entry/real-mailbox/payment rows are completed or tracked with owner/trigger.
• 🔀 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, uploaded/module assets return 200 (per-env symlinks recreated), raw .php under /packages not served, 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.