𝟯 𝗣𝗼𝘀𝘁-𝗗𝗲𝗽𝗹𝗼𝘆 𝗖𝗵𝗲𝗰𝗸𝘀 𝗜 𝗥𝘂𝗻 𝗔𝗳𝘁𝗲𝗿 𝗘𝘃𝗲𝗿𝘆 𝗖𝗹𝗼𝘂𝗱𝗳𝗹𝗮𝗿𝗲 𝗣𝗮𝗴𝗲𝘀 𝗕𝘂𝗶𝗹𝗱
I spent two weeks debugging production issues.
A sitemap rule blocked my XML files. A race condition caused image upload failures. I stopped guessing and added three specific checks to my workflow.
I run these on three Astro 5 SSG sites: aiappdex.com, findindiegame.com, and ossfind.com.
These checks target my actual failure modes.
- Sitemap Verification
I check if sitemap-index.xml returns a 200 status code on all domains. I use curl without redirect following. This catches rules that rewrite URLs incorrectly.
I also check the sub-sitemaps. I verify they contain a minimum number of URLs. For example, if aiappdex.com drops below 1,000 URLs, my data pipeline failed.
- IndexNow Submission
After the sitemap check passes, I run a script to submit URLs to IndexNow. This notifies Bing, Yandex, Naver, and Seznam about new content.
I watch for 403 errors. A 403 usually means my key verification file failed to deploy or a redirect rule broke the path. Catching this early prevents indexing delays.
I run this manually after deployment. This ensures I submit URLs that are actually live on the CDN.
- Scheduled Lighthouse Audits
I run Lighthouse checks via a cron job every Monday. I check one homepage and one deep page per site.
I monitor these metrics:
- Performance (target above 80)
- CLS (target below 0.1)
- Accessibility scores
I use Lighthouse as a trend monitor. I do not block deploys if a score drops slightly. I use the data to spot regressions in my Tailwind config or component layouts.
Why these three?
I do not use uptime monitoring or end-to-end user tests. My sites are static SSG deployments. The entire runtime is pre-built HTML and CSS.
The failure surface is small. These three checks cover the most likely ways my production environment breaks.
Source: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-3j14