You tested on staging. Everything passed. You deployed to production. Now the client is calling.
Sound familiar? It happens to every agency at some point. Staging and production drift apart — different environment variables, different CDN configurations, different caching headers. The code is identical. The behaviour is not.
SiteBrief's new Staging vs Production compare view gives you a side-by-side diff of both environments automatically — so you see the gap before it becomes an incident.
What it compares
The diff covers PageSpeed scores, security header presence, response times, SSL expiry, and uptime. Anything that deviates significantly between environments is flagged in red.
Auto-rollback suggestions
When the compare detects a significant regression — PageSpeed drops more than 20 points, a critical security header disappears, or response time triples — SiteBrief automatically suggests a rollback.
The suggestion shows:
- Which metrics regressed and by how much
- The deploy that introduced the change (if GitHub or GitLab is connected)
- A one-click link to open a revert PR
The common culprits
After analysing hundreds of staging-to-production regressions, the most common causes are:
- Missing security headers on production — staging uses a dev server that adds them automatically; production nginx config doesn't.
- PageSpeed drop from unoptimised images — staging serves WebP; production reverted to PNG after a plugin update.
- Slow response time from cold cache — production Redis cache was flushed during deployment and nobody warmed it.
- SSL near-expiry on production only — cert auto-renewal worked on staging but the production hook was broken.
The compare view catches all of these in under 60 seconds.
How to use it
- Add both your staging and production URLs as sites in SiteBrief
- Set the environment tag (Production / Staging) in site settings
- Open Sites → Compare and select both sites
- SiteBrief runs a fresh scan on both and shows the diff instantly
You can also run the compare automatically on every deploy using the GitHub Actions integration. The action will fail the build if production and staging diverge beyond your configured thresholds.