๐Ÿค–NEW:AI-Powered Incremental Builds โ€” your site updates in under 30 seconds. See what's new โ†’
Zero-Storage Alert Recipes ยท 100% Free

Core Web Vitals Alert Automation Generator

Generate ready-to-deploy Google Apps Script email alerts, Slack/Discord webhooks, and GitHub Actions workflows with zero account storage.

๐Ÿ”’Zero-Storage Privacy Guarantee

We do not store your email or monitor your sites on our servers. These recipes run entirely inside your own Google Apps Script or GitHub account, sending alerts directly to your inbox.

Monitoring Target & Alert Thresholds

/**
 * Google Apps Script - Automated Core Web Vitals Email Monitor
 * 1. Open https://script.google.com/ and create a new project.
 * 2. Paste this code and set a Daily Trigger under Triggers (โฐ icon).
 */
function checkCoreWebVitals() {
  const url = "https://example.com";
  const lcpLimit = 2.5;
  const ttfbLimit = 600;
  
  const endpoint = "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=" + encodeURIComponent(url) + "&strategy=mobile";
  const res = UrlFetchApp.fetch(endpoint, { muteHttpExceptions: true });
  const data = JSON.parse(res.getContentText());
  
  const audits = data.lighthouseResult.audits;
  const lcpSeconds = audits['largest-contentful-paint'].numericValue / 1000;
  const ttfbMs = audits['server-response-time'].numericValue;
  const score = data.lighthouseResult.categories.performance.score * 100;
  
  if (lcpSeconds > lcpLimit || ttfbMs > ttfbLimit) {
    const subject = "โš ๏ธ Core Web Vitals Alert: " + url + " Exceeded Threshold";
    const body = "Core Web Vitals Regression Detected for " + url + "\n\n" +
                 "- Mobile Performance Score: " + score + "/100\n" +
                 "- LCP: " + lcpSeconds.toFixed(2) + "s (Threshold: " + lcpLimit + "s)\n" +
                 "- TTFB: " + Math.round(ttfbMs) + "ms (Threshold: " + ttfbLimit + "ms)\n\n" +
                 "Check PageSpeed Insights for detailed audit.";
    MailApp.sendEmail(Session.getActiveUser().getEmail(), subject, body);
  }
}
Technical Deep-Dive

Setting Up Core Web Vitals Regression Alerts Without a Monitoring Subscription

Last updated: August 2026 โ€ข Reviewed by Nimbica Technical SEO Team

1. The Three Recipes and When to Use Each

The Google Apps Script recipe is the most complete, self-contained option โ€” it calls the PageSpeed Insights API directly, checks the result against your thresholds, and emails you if it fails, all in one script you deploy once. The Slack/Discord Webhook recipe is a delivery function only โ€” it expects you to supply real LCP/TTFB values from your own monitoring logic and formats/sends the alert message. The GitHub Actions recipe scaffolds a scheduled Lighthouse CI audit inside your repository's CI/CD pipeline, which is the best fit if you already have a GitHub-hosted project and want performance regressions caught alongside your other CI checks.

2. How to Deploy the Google Apps Script Recipe

Set your URL and thresholds above, copy the generated script, then go to script.google.com, create a new project, and paste the code in. Under the clock/Triggers icon, add a new trigger: choose the checkCoreWebVitals function, select a time-driven trigger, and set it to run daily (or more often, within API quota limits). The script emails whatever Google account you're logged into when it runs โ€” no external server, database, or subscription is involved.

3. Choosing Sensible Alert Thresholds

Google's published "Good" Core Web Vitals thresholds are LCP โ‰ค 2.5s, INP โ‰ค 200ms, and CLS โ‰ค 0.1 โ€” the default 2.5s LCP slider position matches this. Setting your alert threshold at exactly the "Good" boundary means you're notified the moment a page crosses from acceptable into "Needs Improvement," which is usually what you want for a regression alert. A slightly tighter threshold (e.g., 2.0s LCP) gives you earlier warning before a real user-facing problem develops, at the cost of more frequent alerts from normal variance.

4. What "Zero-Storage" Actually Means Here

This generator runs entirely in your browser to produce the code โ€” your URL and thresholds are never sent to Nimbica's servers, and the resulting scripts run inside infrastructure you control (your own Google account for Apps Script, your own repository for GitHub Actions). Nimbica has no visibility into whether you deploy the script, how often it runs, or what results it produces. This is a genuinely different privacy model than a hosted uptime/CWV monitoring subscription, where a third party's servers do the checking and store your history.

5. Common Setup Mistakes

The most common issue is forgetting to set the trigger after pasting the Apps Script code โ€” the function exists but never runs until a time-driven trigger is added. A second common mistake is checking too frequently against the unauthenticated PSI API and hitting the rate limit, which causes the script to fail silently (add a PSI API key if you need more than one check per day). For the GitHub Actions recipe, forgetting to add the referenced lighthouse-budget.json file will cause the workflow to fail on its first run โ€” create that file with your desired budget thresholds before enabling the schedule.

6. Who Should Use This Tool

Developers and site owners who want basic performance regression alerts without paying for a monitoring subscription, teams already using GitHub Actions who want to add a lightweight Lighthouse budget check, and anyone comfortable maintaining a small script in their own Google account or repository rather than relying on a third-party dashboard.

7. Limitations

These are starting-point code recipes, not a managed service โ€” you are responsible for deploying, maintaining, and troubleshooting them, and Nimbica has no visibility into whether they are running correctly. The Apps Script recipe checks one URL per run using the unauthenticated PSI API's low rate limit; the webhook recipe requires you to supply your own LCP/TTFB source; and the GitHub Actions recipe needs a separately-created budget file and, for chat/email routing beyond GitHub's own notifications, an additional notification step. None of these recipes include historical trend tracking, multi-page monitoring, or team dashboards โ€” for that, a dedicated monitoring service is the better fit.

Frequently Asked Questions

How does this tool generate email alerts without storing my email address on your servers?

To guarantee 100% privacy and zero PII storage, this generator produces standalone Google Apps Script and webhook recipes that run entirely within your own Google account or CI/CD pipelines, emailing you directly via your personal Gmail.

What thresholds should trigger a Core Web Vitals regression alert?

Google defines Good thresholds as LCP โ‰ค 2.5s, INP โ‰ค 200ms, and CLS โ‰ค 0.1. A TTFB exceeding 600ms or an LCP exceeding 2.5s should trigger immediate developer alerts.

Is Google Apps Script free to run for automated daily website monitoring?

Yes. Google Apps Script itself is 100% free with a generous daily fetch quota on standard Google accounts, and a single daily PSI check uses only one of those fetches.

Does the generated Apps Script code need a PageSpeed Insights API key?

It works without one, but the unauthenticated PageSpeed Insights API has a low daily rate limit shared across all unauthenticated callers. For a single daily check this is usually fine, but if you plan to check more frequently or add more sites, get a free PSI API key from Google Cloud Console and append it as `&key=YOUR_KEY` to the endpoint URL in the generated script โ€” this raises your quota and avoids silent failures from rate limiting.

Does the Slack/Discord webhook recipe work as a standalone script?

No โ€” it is a dispatcher function that sends a formatted alert once you call it with real LCP and TTFB values. You need to pair it with a source for those values, such as your own PSI fetch logic (similar to the Apps Script recipe) or your existing monitoring pipeline; the snippet handles formatting and delivery, not the underlying measurement.

Does the GitHub Actions workflow send alerts automatically, or just run the audit?

The workflow scaffolds scheduled Lighthouse CI audits and expects a `lighthouse-budget.json` file (which you create separately) to define pass/fail thresholds. GitHub Actions will show a failed run in its own UI and can notify via GitHub's default email/notification settings when a step fails, but routing that failure into Slack or a custom email requires adding a notification step (many exist as pre-built GitHub Actions) โ€” it is not automatically wired in this starter workflow.