Forem: 137Foundry

7 Free Tools for Measuring and Improving Core Web Vitals

137Foundry — Wed, 29 Apr 2026 11:01:57 +0000

Improving Core Web Vitals doesn't require paid software. The most useful tools in this space are free, and most of them come from Google or are open source. The challenge is knowing which tool to reach for at each stage of the process, since each one measures slightly different things and answers different questions.

This roundup covers the seven free tools worth having in your workflow, what each one is best for, and where each falls short. Used together in the right order, they cover everything from identifying which pages are failing to diagnosing the root cause and verifying the fix.

1. Google Search Console (Core Web Vitals Report)

Google Search Console is the starting point for any Core Web Vitals project. The Core Web Vitals report shows field data from the Chrome User Experience Report, grouped by URL pattern, and categorized into poor, needs improvement, and good. It's the only place to see how your site is actually performing for real visitors using real devices.

Best for: Identifying which page templates are failing in the field and getting a priority-ranked list of URLs to focus on. The report groups similar URLs (like all blog post pages) together so you can see which template types need the most attention, rather than having to check every URL individually.

Limitation: The data is aggregated and delayed by approximately 28 days. You can't see individual user sessions, and you can't isolate which specific device types or geographies are driving poor scores. It tells you what to fix but not precisely why.

2. Chrome DevTools (Performance Panel and Web Vitals Extension)

Chrome DevTools is the most powerful diagnostic tool for Core Web Vitals because it lets you run the page in your own browser, reproduce issues locally, and trace them to specific resources and code paths. No external service required.

The Performance panel records a timeline of everything the browser does during page load, including resource fetches, JavaScript execution, layout and paint events, and user interactions. The Experience row highlights layout shift events. Long tasks are visible in the Main thread track. CPU and network throttling let you simulate slower devices. The Interactions panel, added more recently, records every interaction and shows its breakdown across input delay, processing time, and presentation delay, which is exactly what you need for INP debugging.

Best for: Diagnosing the exact cause of an LCP delay, identifying which elements are shifting for CLS, and profiling long JavaScript tasks or event handlers that cause INP.

Limitation: Lab conditions. Your machine's CPU speed and browser state don't match a typical user's device. Installed extensions and cached resources can affect results in ways that don't reflect the real user experience. Run tests in a clean Incognito window with throttling enabled for the most representative lab results.

3. Lighthouse (via DevTools or CLI)

Lighthouse is Google's open-source automated auditing tool. It runs a battery of tests against a page, including Core Web Vitals, accessibility, SEO, and best practices, and produces a scored report with specific, prioritized recommendations. The Lighthouse tab in Chrome DevTools runs it in a few clicks. The CLI version allows it to run in a CI/CD pipeline as a quality gate on every pull request.

Best for: Getting a structured, actionable report on what to fix, with explanations of each issue and direct links to guidance. Running it in CI catches performance regressions before they reach production. The JSON output format makes it possible to track scores over time programmatically.

Limitation: Lighthouse runs in lab conditions and is particularly sensitive to CPU load on your local machine. Scores from DevTools can vary significantly between runs if other applications are running. For stable, repeatable scores, use the CLI version in a clean environment with a consistent CPU profile.

Photo by Markus Winkler on Pexels

4. WebPageTest

WebPageTest runs page load tests from real browsers on real hardware in locations around the world. Unlike local DevTools tests, a WebPageTest run from a specific city on a specific device profile reflects what a user in that location on that device would actually experience. The waterfall chart shows every resource fetch in sequence, making it easy to see exactly what is happening at each millisecond of page load.

Best for: Reproducing performance issues that only appear on slower networks or lower-end devices, testing from multiple geographies, and getting a detailed waterfall view of resource loading order and timing. The filmstrip view shows what the page looks like at each second of load, which is useful for identifying the LCP element and confirming when it actually renders.

Limitation: Free tier has rate limits and queued test execution. Not suitable for rapid iterative testing during development. Plan on running a few targeted tests at key milestones rather than using it as a fast feedback loop.

5. GTmetrix

GTmetrix runs performance tests from multiple locations and presents a combined score alongside a Lighthouse report and a filmstrip view of the page loading in frames. The comparison feature lets you run tests before and after a change and see the difference side by side. The filmstrip view makes it easy to see exactly when the LCP element paints and whether any layout shifts are visible between frames.

Best for: Quickly verifying that a fix improved LCP and getting a visual sense of how the page loads frame by frame. The before/after comparison is particularly useful for communicating performance improvements to stakeholders who want to see a visual difference.

Limitation: Free tier is limited to specific test locations and a limited number of tests per month. For teams that run many tests during an optimization sprint, the free tier can run out quickly.

6. HTTP Archive (Research and Benchmarking)

HTTP Archive is a nonprofit project that crawls millions of web pages on a regular schedule and archives their performance data. The data is queryable via BigQuery for custom analysis. The site publishes regular Web Almanac reports with detailed analysis of web performance trends, broken down by page type, CMS, and technology stack.

Best for: Benchmarking your site's performance metrics against industry-wide averages, understanding how common specific issues are across the web, and tracking how performance patterns evolve over time. The Web Almanac's annual performance chapter is one of the best publicly available analyses of Core Web Vitals across the web.

Limitation: HTTP Archive data is aggregate and historical. It's a research and benchmarking tool, not a diagnostic tool for your specific site. There's a meaningful learning curve to querying the data effectively via BigQuery.

7. web.dev (Learning Resource and Measure Tool)

web.dev is Google's resource for web performance best practices. It hosts a Measure tool for running a Lighthouse audit from a URL, but more importantly it's where Google publishes detailed technical guidance on Core Web Vitals, including how each metric is calculated, what causes failures, and how to fix specific issues. The articles are written by the Chrome team members who define the metrics, which makes them unusually authoritative.

Best for: Understanding the "why" behind a score, reading Google's official guidance on LCP, CLS, and INP, and finding detailed case studies from sites that have improved their scores. When you find an issue in DevTools or Lighthouse and need to understand it deeply before writing a fix, web.dev is where you go.

Limitation: It's documentation and guidance, not a diagnostic tool for your specific site. Use it alongside the other tools in this list.

Photo by ninocare on Pixabay

How These Fit Together in Practice

A practical Core Web Vitals workflow uses these tools in a specific sequence. Start with Search Console to find which page templates have field data problems and which URLs to prioritize. Run those specific URLs through WebPageTest or GTmetrix to get a baseline lab measurement. Use Chrome DevTools to drill into the specific resources and code causing the issues on those pages. Use Lighthouse to generate a structured list of recommendations. Use web.dev to read the guidance for each issue type before writing fixes. Then run WebPageTest or GTmetrix again after shipping the fix to confirm the score moved.

For a step-by-step guide to using these tools in a real production audit, 137Foundry published a full walkthrough that covers the complete process from field data to fix verification: How to Audit and Fix Core Web Vitals on a Production Website.

The tooling in this space is genuinely excellent and genuinely free. The bottleneck is rarely tool access. It's knowing which issues to prioritize, how to interpret what the tools are reporting, and how to trace a reported problem to the specific code that's causing it. That part comes from running the process on real sites and building familiarity with what each tool is actually measuring.

Why Cumulative Layout Shift Is Harder to Fix Than It Looks

137Foundry — Wed, 29 Apr 2026 11:01:52 +0000

Of the three Core Web Vitals, Cumulative Layout Shift often surprises developers. LCP is a loading problem. INP is a JavaScript problem. CLS looks like it should be solved by adding width and height to images, and then it turns out your score barely moves after you do that.

The reason CLS is deceptively hard is that the score accumulates from multiple sources, most of which are not images. A CLS score is the sum of all unexpected layout shifts during a page session, and the sources include web fonts, injected third-party content, dynamic banners, browser-extension interference, and animated elements that change dimensions without user interaction. Fixing images helps. It usually isn't enough on its own.

How CLS Is Actually Calculated

The metric combines the "impact fraction" (how much of the viewport moved) with the "distance fraction" (how far it moved). A shift that moves a large block of content a short distance can score similarly to one that moves a small element a long distance. Understanding the formula matters because it reveals that small-looking shifts can have significant score impact if they affect large portions of the viewport.

CLS is also session-windowed. The browser groups shifts into windows of up to 5 seconds, with a maximum gap of 1 second between shifts. The score for a window is the sum of all shifts in that window. Your reported CLS is the worst window's score.

This windowed approach means that a series of small shifts that happen in quick succession can accumulate into a high CLS score, even if no single shift is dramatic. Pages that load ads or dynamic content in stages often have this pattern. What looks visually like minor movement repeatedly is registering as a high CLS window score.

Photo by 2211438 on Pixabay

The Sources Most Teams Miss

Web font loading. When font-display: swap is set, the browser renders text in the fallback font first, then swaps to the web font when it loads. If the web font has different metrics than the fallback (different x-height, character width, or line height), the swap causes a layout shift. This is a common source of CLS on editorial sites and landing pages that use distinctive typography.

The fix is either to use font-display: optional (no swap at all, web font only used if loaded in the first render frame) or to use the CSS size-adjust, ascent-override, descent-override, and line-gap-override descriptors to align the fallback font metrics to the web font. The latter approach is more complex but preserves the web font experience for users on fast connections.

Ads and embeds. Ad networks and embedded third-party widgets frequently insert content into reserved or unreserved slots after the page has painted. A cookie consent banner that appears above the page header is a classic example. An ad that loads into a container without a declared minimum height is another.

For ad slots, always declare a minimum container height in CSS matching the expected ad dimensions. For consent banners and notifications, wrap them in a container with a declared minimum height even if you plan to animate them in. The declared height prevents the shift on insertion.

Animations. CSS animations that change top, left, margin, or padding cause layout shifts because those properties affect how the browser positions surrounding elements. Animations that use transform: translate() do not cause layout shifts because transforms operate in the compositor layer and don't affect layout flow. Review any CSS that animates position-affecting properties and convert them to transform-based equivalents.

Dynamically loaded content above existing content. Any JavaScript that inserts content above already-painted content will cause a layout shift if the existing content moves down. This includes chat widgets that appear in a fixed position but whose initialization changes layout, notification banners inserted at page top, and lazy-loaded content sections above the fold that load after user scroll.

Why Tools Don't Always Catch Everything

Lab tools like Lighthouse capture CLS from a single simulated page load in a clean browser context. They can't reproduce a shift caused by a browser extension that adds toolbar content. They can't always reproduce shifts from ad networks whose ad content varies by visitor or by geographic location. And they don't simulate the range of user devices and system fonts that affect font rendering and fallback behavior.

Field data from Google Search Console and the Chrome User Experience Report captures the actual 75th-percentile CLS across real visits. If your lab CLS score is good but your field data shows poor CLS, the problem is almost certainly coming from a source that varies by visitor, like ads, extensions, or system font differences between operating systems.

MDN Web Docs has detailed documentation on the Layout Instability API, which is what the browser uses to measure CLS. Reading the spec-level description of what constitutes a layout shift and what doesn't is useful when you're debugging an unexpected score. Not every visual change counts as a shift; only unexpected changes to the start position of layout-affecting elements in the viewport trigger the metric.

Where to Start Debugging

The Chrome DevTools Performance panel shows layout shifts as events in the timeline. Click on any shift event to see which elements moved and what triggered the shift. The "Experience" row in the timeline highlights shift events specifically, and clicking into one shows the affected elements and the computed CLS score contribution from that event.

For shift events that happen after initial load (caused by ads, dynamic content, or JavaScript-triggered changes), set up a longer recording in DevTools that captures user interaction or page scroll. Some shifts only appear when the user interacts with specific page elements or when a page reaches a certain scroll position. Record a realistic user session rather than just the initial page load.

Photo by Google DeepMind on Pexels

Start with the shifts that appear in the first 2.5 seconds of page load, since those tend to have the highest impact on the reported score. Work through the sources in order: images without explicit dimensions, web font swaps, injected content, and animated elements using layout-affecting properties. Use a real device on a slower network profile to surface shifts that only appear under load conditions.

Verifying the Fix

After applying CLS fixes, measure the change in both lab tools and, over time, in field data. For font-related fixes, disable web fonts entirely in DevTools and check whether the content changes visually. If the text barely changes appearance, font-display: optional is safe to deploy. For ad-slot fixes, use DevTools' network throttle to load the page slowly and observe whether content shifts when ads inject.

Keep in mind that a CLS fix on one template doesn't mean the same fix applies everywhere. A site with multiple page types may have different CLS sources on article pages versus category pages versus landing pages. Audit each template type separately.

For a broader look at all three Core Web Vitals metrics and how to address LCP and INP alongside CLS, 137Foundry put together a complete production audit guide: How to Audit and Fix Core Web Vitals on a Production Website.

"CLS is the metric where I see teams get stuck longest. They fix the images, run Lighthouse again, see a slightly better number, and assume it's done. But field data still shows poor. The remaining score almost always comes from font swaps, third-party injections, or animations that nobody thought of as layout-affecting." - Dennis Traina, founder of 137Foundry

CLS requires systematic enumeration of every source of visual change on a page, not just the obvious ones. The good news is that once you've worked through that enumeration on a given page template, the fixes usually stay fixed. Unlike INP, which can regress with any new JavaScript, CLS problems are structural and tend to stay solved once the root cause is addressed properly.

The Real Cost of Silent Data Pipeline Failures

137Foundry — Tue, 28 Apr 2026 04:18:37 +0000

A loud failure - a crash, an error email, an alert firing at 3am - is a recoverable problem. You know something broke, you know when it broke, and you can investigate.

A silent failure is different. The pipeline runs. No errors are logged. No alerts fire. The data is wrong, or incomplete, or stale, and nobody knows until someone notices that the numbers don't add up. At that point, the first question is "how long has this been happening?" and the answer is almost always longer than you expected.

This piece is about silent failures: why they happen, what they cost, and how to design pipelines that surface problems rather than hiding them.

Why Data Pipelines Fail Silently

Silent failures have a structural cause: the code treats a missing or incorrect result as a valid outcome.

The most common pattern is this: a pipeline pulls records from an API, and the API starts returning fewer records than expected - maybe due to a rate limit, a pagination bug, or a filter that was added on the source side. The pipeline processes the records it receives, writes them to the destination, and logs success. From the pipeline's perspective, nothing went wrong. From the business's perspective, 30% of the data from the last two weeks is missing.

Another common pattern: a field in the source system gets renamed or its format changes. The pipeline's transformation code mapped from the old field name to the destination field. Now the source returns null for that field (the old name doesn't exist anymore), the transformation writes null to the destination, and every record for the last three days has a null value where it should have a meaningful value.

Both cases represent the same design failure: the pipeline has no way to distinguish between "everything worked correctly" and "something changed and we processed garbage."

The Business Costs

The direct cost of a silent data pipeline failure is the bad data that reaches reporting, operations, or downstream systems. But the cost multipliers are significant:

Time to detection. Silent failures are found by humans reviewing output, not by automated monitoring. The average time-to-detection is measured in days to weeks for pipelines without monitoring. Every day of latency compounds the amount of data that needs to be corrected.

Recovery effort. When a pipeline has been silently dropping records for two weeks, recovering requires identifying which records were affected, re-running the pipeline for the affected time window, deduplicating any overlap with records that were correctly written, and verifying the corrected data. This is significantly more expensive than the incremental fix of a loud failure caught immediately.

Trust erosion. After a team discovers that the pipeline has been silently producing wrong data, the standard response is to stop trusting the data source entirely until it's verified. This often means manual data validation work that bypasses the pipeline - which defeats the purpose of automation and creates a parallel data entry problem.

Decision quality. If the bad data reached business decisions before anyone noticed - a performance report, a customer analysis, a budget forecast - those decisions were made on incorrect information. Quantifying this cost is harder, but it's real.

Photo by panumas nikhomkhai on Pexels

What Silent Failures Look Like in Practice

A few real patterns:

The vanishing records case. A pipeline extracts orders from an e-commerce platform. The platform adds a new required field to its API response. The pipeline's JSON parser doesn't handle the new field structure, throws an exception in the transformation step, catches it with a broad except Exception handler, logs a debug message, and skips the record. The pipeline completes with 0 errors and 15% fewer records than yesterday. The monitoring dashboard shows "Pipeline: OK."

The null propagation case. A pipeline syncs contact records from a CRM. An admin renames the "Company" field to "Organization" in the CRM. The pipeline's field mapping extracts "Company," which now returns null, and writes it as null to the destination. Every record written after the rename has a null company field. Reports that group by company show an explosion of records with no company associated.

The stale data case. A pipeline is supposed to run every hour. A deployment changes the scheduling configuration. The pipeline stops running. No records fail - there simply are no new records. Nobody notices for three days because the data isn't wrong, it's just not updating.

Each of these is detectable with basic monitoring. None of them are detectable without it.

"We've done data audits on pipelines that have been running for over a year where the team assumed the data was correct because nothing had ever crashed. The combination of no monitoring and optimistic error handling is how you end up with analytics you can't trust and can't recover." - Dennis Traina, founder of 137Foundry

Designing for Visibility

The fix is not complex. Five things give you visibility into a data pipeline:

1. Count records at each stage. How many records were extracted? How many passed transformation? How many were successfully loaded? If the ratio is unexpected, alert on it. A 90% drop in extraction volume without a corresponding change in the source system is a problem.

2. Track run timing. Log start time, end time, and duration for each run. Alert when a run takes significantly longer than the historical average. Alert when a run hasn't started within the expected window.

3. Separate transient and structural errors. Transient errors (rate limits, network timeouts) should be retried automatically and logged. They should alert if they exceed a threshold. Structural errors (records that fail transformation due to unexpected field values) should never be swallowed silently. Log the record, the field, and the value. Alert if structural errors exceed zero or a small threshold per run.

4. Validate schema on extraction. When extracting data, compare the schema of the API response to a stored baseline. If a field appears that wasn't there before, or a field that was previously present is now absent, log a warning and alert. Schema drift is the most common cause of silent failures.

5. Store per-run metrics in a queryable log. Write a row to a log table for each run: records extracted, records failed, records loaded, run duration, error count. This gives you a historical record that's useful for diagnosing issues after the fact.

Photo by Lukas Blazek on Pexels

The Cost of Retrofitting Monitoring

One reason monitoring often gets deferred is that it feels like overhead at the start of a project, when the team is focused on getting the pipeline working at all. The irony is that retrofitting monitoring onto a pipeline that's been running without it is significantly more expensive than building it in from the start.

Retrofitting requires: understanding the existing behavior well enough to define normal baselines, adding logging infrastructure to code that wasn't designed for it, deploying changes to a running pipeline without disrupting data flow, and verifying that the monitoring correctly reflects actual pipeline state.

Building monitoring in from the start takes a fraction of that time because the logging points are natural integration points in the code architecture.

For the practical pipeline architecture that includes monitoring as a first-class concern - alongside idempotent loads, incremental extraction, and error handling - How to Build an ETL Pipeline for Business Data Syncing covers each piece in sequence.

https://137foundry.com works with businesses on data pipeline design and implementation. The AI automation and data integration services include both pipeline architecture and the operational monitoring setup that makes pipelines trustworthy rather than just functional.

For monitoring infrastructure, Prometheus and Grafana are widely used for pipeline metrics collection and alerting. For orchestration that includes built-in run observability, Apache Airflow tracks run history, task durations, and failure states in a web UI. Python with SQLAlchemy is the standard stack for custom pipeline implementation with relational state management.

How to Add Error Handling and Monitoring to a Data Pipeline

137Foundry — Tue, 28 Apr 2026 04:18:34 +0000

Most data pipeline guides cover the happy path: extract data, transform it, load it to the destination. What they skip is everything that happens when the path isn't happy: the API that returns unexpected data, the transformation that fails partway through, the destination write that times out after writing 400 of 500 records.

This guide is the other half: how to handle errors correctly, how to monitor pipeline health, and how to make your pipeline re-runnable after a failure.

Step 1: Categorize Your Error Types

Before writing error handling code, decide which category an error belongs to. The handling is different for each type.

Transient errors are temporary conditions that resolve themselves: rate limit exceeded, connection timeout, destination temporarily unavailable. These should be retried automatically with exponential backoff. They should not fail the pipeline on first occurrence. After a configurable number of retries, they should escalate to an alert.

Structural errors are problems with the data itself: a required field is null, a value doesn't match the expected type, a foreign key doesn't exist in the destination. These records cannot be processed with the current transformation logic. They should be written to a dead-letter log (with the record content, error type, and timestamp) and skipped. The pipeline should continue processing other records. At the end of the run, alert if structural error count exceeds zero or a defined threshold.

Fatal errors are conditions that make continued execution meaningless: the source system is completely unavailable, authentication has failed, the destination schema has changed in a way that invalidates all records. These should fail the pipeline immediately, log the full context, and alert immediately. Do not attempt to continue.

The most common mistake is using a single broad exception handler that converts structural and fatal errors into transient ones. This produces the silent failure pattern where the pipeline "succeeds" by swallowing exceptions.

Step 2: Implement Retry Logic for Transient Errors

A basic exponential backoff implementation for transient errors:

import time
import random

def with_retry(fn, max_attempts=5, base_delay=1.0, max_delay=60.0):
    for attempt in range(max_attempts):
        try:
            return fn()
        except TransientError as e:
            if attempt == max_attempts - 1:
                raise
            delay = min(base_delay * (2 ** attempt) + random.uniform(0, 1), max_delay)
            log.warning(f"Transient error on attempt {attempt + 1}: {e}. Retrying in {delay:.1f}s")
            time.sleep(delay)

The jitter (random.uniform(0, 1)) prevents multiple concurrent pipelines from all retrying at the same time, which can amplify load spikes on the source system.

The important detail: define TransientError as a specific exception class (or a set of HTTP status codes: 429, 503, 502) rather than catching all exceptions. Retrying a ValueError or KeyError is not useful and hides bugs.

Step 3: Build a Dead-Letter Log for Structural Errors

Records that fail transformation should not be silently dropped. Write them to a dead-letter log table or file with enough context to investigate:

def process_record(record, dead_letter_log):
    try:
        transformed = transform(record)
        return transformed
    except StructuralError as e:
        dead_letter_log.write({
            "timestamp": utcnow(),
            "source_id": record.get("id"),
            "error_type": type(e).__name__,
            "error_message": str(e),
            "raw_record": json.dumps(record),
            "pipeline_run_id": current_run_id()
        })
        return None

The pipeline_run_id is critical for correlating dead-letter records with a specific run when debugging later.

At the end of each run, count dead-letter entries created during the run. If the count exceeds your threshold (zero for a stable pipeline, or a small absolute number), include the count in your run summary and trigger an alert.

Photo by Markus Spiske on Pexels

Step 4: Add Run-Level Metrics Logging

Write a metrics record at the end of each pipeline run. This is separate from error logging - it captures the overall run health:

run_metrics = {
    "run_id": run_id,
    "pipeline_name": "crm_to_warehouse",
    "started_at": start_time,
    "completed_at": utcnow(),
    "duration_seconds": (utcnow() - start_time).total_seconds(),
    "records_extracted": extracted_count,
    "records_transformed": transformed_count,
    "records_loaded": loaded_count,
    "structural_errors": dead_letter_count,
    "transient_errors_retried": retry_count,
    "status": "success" if dead_letter_count == 0 else "partial"
}
metrics_log.write(run_metrics)

With this log table, you can query:

"How many records did this pipeline process yesterday vs the historical average?"
"How many structural errors have accumulated this week?"
"Which runs took significantly longer than usual?"

These queries are the basis for alerting that doesn't require anyone to look at logs manually.

Step 5: Implement Schema Validation

Schema drift - unexpected changes to the source API's response format - is the most common cause of silent failures that aren't caught by error handling. Add explicit schema validation at the extraction step:

EXPECTED_FIELDS = {"id", "email", "created_at", "updated_at", "status"}

def validate_schema(records):
    if not records:
        return
    sample_keys = set(records[0].keys())
    new_fields = sample_keys - EXPECTED_FIELDS
    missing_fields = EXPECTED_FIELDS - sample_keys
    if new_fields:
        log.warning(f"New fields detected in source: {new_fields}")
        alert("Schema change detected", details={"new_fields": list(new_fields)})
    if missing_fields:
        log.error(f"Expected fields missing from source: {missing_fields}")
        raise FatalError(f"Required fields missing: {missing_fields}")

New fields are a warning (the API added something, you might want to include it). Missing required fields are a fatal error (the API removed something your transformation depends on).

"A pipeline that validates its input schema and alerts on changes costs almost nothing to build. But it's the single most valuable defensive measure you can add, because schema changes in source systems are the failure mode that catches teams off guard most consistently." - Dennis Traina, founder of 137Foundry

Step 6: Make the Pipeline Re-Runnable

A pipeline that can be safely re-run after a partial failure is worth significantly more than one that can't. Two properties make this possible:

Checkpointing. Store the high-water mark after each successful batch write. If the pipeline fails, restart from the last checkpoint rather than from the beginning. The checkpoint is typically a timestamp or sequence number stored in a persistent store (a database row, a file, a cache entry).

Idempotent loads. Use upsert semantics at the destination rather than insert. An upsert with a unique key (customer ID, order number, record hash) ensures that re-running a batch doesn't create duplicate records. This interacts with checkpointing: if your checkpoint has any overlap window (you re-process the last N records for safety), upserts ensure the overlap records are updated rather than duplicated.

Setting Up Alerting

With run metrics logging in place, alerting is straightforward. Three alert conditions cover most critical failures:

Pipeline didn't run. Alert if no run has completed within expected_interval * 1.5 of the last successful run.
Record count anomaly. Alert if records_extracted is more than 30% below the historical average for this pipeline and time window.
Structural errors above threshold. Alert if structural_errors > 0 (or your defined threshold).

These three conditions catch the vast majority of real pipeline failures without requiring manual monitoring.

How to Build an ETL Pipeline for Business Data Syncing covers the extraction and load design that this error handling layer builds on top of - incremental extraction, idempotent upserts, and checkpoint management in an integrated design.

For help building data pipelines with these operational properties from the start, https://137foundry.com works with businesses on both architecture and implementation. The data integration services cover the full pipeline lifecycle, including the monitoring setup that makes pipelines trustworthy in production.

For pipeline implementation, Python with SQLAlchemy is the standard stack for custom ETL with relational databases. PostgreSQL handles both pipeline operational state (dead-letter tables, run logs) and destination storage. For orchestration-level error handling and retry policies, Apache Airflow provides per-task retry configuration and failure branching.

Photo by panumas nikhomkhai on Pexels

How to Build a Vendor Scoring Rubric That Stakeholders Actually Trust

137Foundry — Sat, 25 Apr 2026 11:28:03 +0000

A vendor scoring rubric sounds like the kind of bureaucratic box-ticking that delays decisions rather than producing them. Used correctly, it does the opposite: it forces the committee to agree on criteria before they see the vendors, reduces the influence of whoever talks loudest in the room, and gives minority viewpoints a visible record in the final data.

The key distinction is whether the rubric was built before the demos or after. A rubric built after the demos is usually rationalization. A rubric built before the demos is a decision tool.

Step 1: Identify Your Evaluation Dimensions

Start by listing every dimension that matters for the decision. Group these into functional, operational, and vendor relationship categories:

Functional: Does the software do what you need it to do? This includes core features, edge case handling, integration capabilities, and the UX quality for your team's daily workflows.

Operational: How does the software fit into your environment? This covers security and compliance, implementation timeline, data migration complexity, support tier availability, and uptime guarantees.

Vendor relationship: What is the vendor like to work with? This includes response times during the evaluation, flexibility on contract terms, references from current customers, and the stability of the vendor's business.

For each dimension, list the specific questions or scenarios you'll use to evaluate it. "Security and compliance" is not evaluable. "SOC 2 Type II certified with audit reports available, GDPR-compliant data processing agreement available for review" is evaluable.

User review platforms like G2 can help you identify evaluation dimensions you might otherwise miss. The most helpful negative reviews on G2 consistently surface the same categories of failure: poor support responsiveness, missing integrations, confusing pricing, and slow implementation timelines. Running through the top negative reviews for vendors you're considering before you finalize your evaluation dimensions often surfaces operational and vendor relationship criteria that don't appear in feature comparison lists but have significant impact on day-to-day experience. What users repeatedly complain about after twelve months of use is worth weighting heavily as an evaluation dimension before any demos.

Step 2: Assign Weights Before Any Demos

Once you have your evaluation dimensions, assign weights before you see any vendor. Weights represent how much each dimension affects the decision relative to others.

A simple weighting system:

Weight 3: Deal-breaker criteria. A vendor that fails this dimension is out.
Weight 2: Important but negotiable criteria. Strong performance here moves a vendor up significantly.
Weight 1: Nice-to-have criteria. Good to have, but not decision-driving.

If the committee disagrees on weights, that's the most important disagreement to resolve before the demos start. A committee member who weights "API access" at 3 and another who weights it at 1 have fundamentally different visions of what the software needs to do. Better to surface and resolve that now.

Document the final weights with committee sign-off. This step sounds bureaucratic but prevents the weights from being revised retroactively to favor a vendor someone liked.

Photo by Markus Winkler on Pexels

Step 3: Define the Scoring Scale

The scoring scale should be simple enough that committee members can apply it consistently. A three-point scale works well:

3: Exceeds requirements. The vendor handles this better than we expected or needs.
2: Meets requirements. The vendor handles this adequately for our use case.
1: Partially meets requirements. The vendor can address this with workarounds or configuration.
0: Does not meet requirements. The vendor cannot address this criterion.

The difference between 1 and 0 is important: 1 means the gap can be closed at acceptable cost; 0 means it can't. A vendor that scores 0 on a Weight-3 criterion is automatically disqualified regardless of how they score elsewhere. Build that logic into your rubric explicitly so there's no ambiguity.

Step 4: Score Independently Before Comparing

After each demo, each committee member should complete their scores independently before the group discussion. Group discussion before independent scoring produces groupthink -- the strongest personality or the most confident speaker dominates.

Collect all scores before any comparison discussion. When you reveal the aggregate, disagreements become visible: two people scored a criterion 3 and two scored it 1. Those disagreements are where the useful discussion lives. Why does one person think it meets requirements and another think it doesn't? Usually the answer reveals a difference in what each person thought the scenario was testing.

This step slows down the scoring process by about thirty minutes per vendor. It produces decisions that hold up better under scrutiny, because every committee member can trace the final recommendation back to specific evaluation data.

Step 5: Guard Against Score Adjustments

The most common way rubrics fail is retroactive adjustment. After the demos, someone on the committee decides that a criterion they previously weighted at 1 should actually be a 3, because the vendor they prefer scored poorly on a high-weight criterion and someone else's preferred vendor scored well on a low-weight one.

The way to prevent this is to have the completed weights and criteria locked by a neutral party (often the evaluation lead) before the demos. Changes to the rubric after any demo require documented justification and committee agreement.

This sounds overly procedural. In practice, it rarely comes up when everyone knows the lock is in place. The threat of "we'll need to document why we changed this weight after seeing the demos" is usually enough to prevent casual retroactive adjustment.

Using the Rubric Output

The rubric output is a starting point for the decision, not the decision itself. A vendor who scores 87 vs. 83 on a rubric isn't definitively better -- the margin is too small to be meaningful given the inherent subjectivity in scores.

What the rubric output is good for: identifying clear winners, identifying clear losers, and surfacing the criteria where the committee is genuinely split. The rubric should tell you which vendors to eliminate and what the final decision comes down to.

For close calls, the rubric data supports a structured conversation rather than settling it by fiat. If two vendors are within a few points and the committee is split, the next step is to examine the specific criteria where they differ, not to run the evaluation again.

The rubric also serves a documentation purpose beyond the immediate decision. A completed rubric shows which criteria and weights the committee agreed on before any demos, the independent scores each evaluator assigned, and the reasoning behind close calls. That record is useful if the decision needs to be justified to a CFO or board, and it's valuable a year later when the winning vendor hasn't delivered as expected and you need to determine whether that was a product failure or an evaluation gap. Saving the rubric as a template also reduces setup time for future evaluations -- most organizations face similar evaluation categories across different software purchases, and a reusable structure with your standard weighting logic is worth maintaining.

The vendor evaluation framework from 137Foundry covers rubric design alongside requirements definition, short-listing, demo structure, and stakeholder alignment as a complete process. 137Foundry works with companies on technology initiatives where structured vendor selection is part of a larger implementation project.

For research on decision-making quality in group procurement processes, Harvard Business Review and Gartner both publish on sourcing and vendor selection methodology with evidence on which process structures produce better outcomes.

12 Free Tools and Resources for Running a Software Vendor Evaluation

137Foundry — Sat, 25 Apr 2026 11:28:02 +0000

Software vendor evaluations are process-heavy and produce better decisions when you have the right tools for each stage. Most of what you need is either free or already in your organization's toolbox. Here are twelve resources worth using, organized by evaluation stage.

Discovery and Market Research

1. G2

G2 is a software review platform with user reviews, feature comparisons, and market category maps. For the discovery stage, the category pages give you a realistic market overview for most software verticals -- who the major players are, what features are standard, and what users commonly complain about. The user reviews are more candid than vendor marketing and are often more useful than analyst reports for mid-market procurement.

The "Most Helpful Negative Reviews" filter on each vendor's G2 profile is particularly valuable. Negative reviews from verified users consistently surface the same categories of problems: poor customer support, missing integrations, confusing pricing, slow implementation. Seeing the same criticism from fifteen different reviewers over the past twelve months is a stronger signal than any single reference call a vendor arranges for you. The category comparison tools let you build a side-by-side feature matrix in minutes rather than hours.

2. Gartner

Gartner publishes Magic Quadrant reports that categorize vendors by execution strength and vision in established software categories. The full reports require a paid subscription, but the summary findings are frequently cited in vendor RFP responses and public summaries. For enterprise software procurement, Gartner's category definitions help you understand where a vendor sits in the market and who their primary competition is.

The Magic Quadrant positioning (Leader, Challenger, Visionary, Niche Player) is useful context but not a substitute for your own evaluation. A Niche Player that specializes in your industry or company size may be a better fit than a Leader built for a different use case. Gartner's positioning reflects execution at scale and vision breadth, not fit for your specific requirements. Use it to build your initial vendor list, then evaluate based on your own criteria.

3. Harvard Business Review

Harvard Business Review publishes research on procurement strategy, vendor management, and technology decision-making. The articles on make-vs-buy decisions and supplier selection are directly applicable to software evaluations. The research is written for business leaders rather than IT specialists, which makes it useful for building cross-functional alignment on procurement criteria.

Requirements and Scoring

4. Notion or Confluence (your existing tools)

Most teams already have access to a wiki or collaborative document tool. For vendor evaluation, these tools work well for writing and circulating the requirements document, storing the vendor comparison rubric, and documenting scoring decisions. The value isn't in the tool -- it's in having a single shared location that all stakeholders can reference.

5. Google Sheets or Excel

A scoring rubric in a spreadsheet is the standard approach for comparable vendor evaluation. Rows are requirements or evaluation criteria; columns are vendors; cells are scores. The spreadsheet calculates weighted totals automatically. The file lives somewhere the full committee can access, reducing the risk of different people working from different versions of the evaluation.

For weighted scoring, the formula structure is straightforward: each criterion has a weight (typically 1-3 based on priority) and a score (typically 1-3 based on fit), and the weighted total is the sum of weight-times-score across all criteria.

Vendor Research

6. LinkedIn

LinkedIn is useful for two specific evaluation tasks. First, checking the vendor's team size and growth trajectory -- a vendor that was 50 people two years ago and is now 200 is a different business risk than one that was 200 and is now 50. Second, finding current and former customers who might give you a candid reference call, which is more reliable than vendor-provided references.

7. CrunchBase

Crunchbase provides funding history, investor profiles, and company data for private companies. For SaaS vendors, knowing how much runway they have and who their investors are helps you assess business continuity risk. A vendor on their last funding round with a high burn rate is a different counterparty risk than one that recently closed a Series B.

Photo by StartupStockPhotos on Pixabay

8. TrustRadius

TrustRadius is a software review site similar to G2 but with a different reviewer community. Checking both sites for a vendor you're seriously evaluating gives you a broader sample of user perspectives. Reviews that appear on both platforms (different users, similar conclusions) are more reliable signals than reviews that appear on only one.

Legal and Contract Research

9. NIST

NIST publishes cybersecurity and data protection frameworks that are useful for evaluating a SaaS vendor's security posture. The NIST Cybersecurity Framework is a commonly cited reference for what "good security" looks like, and asking vendors how they map to NIST controls is a quick way to assess whether their security practices are mature or aspirational.

For practical security evaluation, the most useful question to ask vendors is whether they have a current SOC 2 Type II report available for review. SOC 2 Type II means an independent auditor has verified their security controls over a six-to-twelve month period. Vendors who have only Type I (a point-in-time snapshot) or no SOC 2 at all are at a materially lower security maturity level than vendors with current Type II certification. NIST guidance provides the framework for understanding what those controls cover.

10. OECD Guidelines

OECD publishes guidelines on data governance and digital trade that are useful context for evaluating vendor contracts that involve data processing, especially for international operations. The guidelines help non-legal stakeholders understand what standard protections look like and what terms are worth negotiating.

Post-Selection

11. 137Foundry Vendor Evaluation Framework

full-stack development firm 137Foundry publishes a complete vendor evaluation framework covering requirements definition, short-listing, structured demos, scoring, stakeholder alignment, and contract negotiation. The framework is designed for teams that run one to two software evaluations per year and need a repeatable process that doesn't require a full procurement department.

The services overview covers the types of engagements where vendor selection happens as part of broader technology initiatives.

12. Forrester

Forrester publishes research on technology procurement and vendor management, including reports on SaaS contract best practices and vendor relationship management. For teams doing a significant software evaluation for the first time, Forrester's publicly available blog posts and summaries provide useful framing for what to expect in contract negotiations and post-implementation support.

The most important tool in any vendor evaluation isn't on this list: it's a clearly written requirements document that the full committee agrees on before any vendor conversations begin. Without that, no amount of market research, scoring, or legal review will produce a decision that sticks.

The sequence matters as much as the tools. Start with G2 and Gartner for market orientation before building a vendor list. Move to LinkedIn and Crunchbase for vendor-specific research before scheduling demos. Use NIST and OECD guidelines when reviewing security and compliance terms before signing. The tools above are useful in context; pulling from them at the wrong stage of the evaluation creates noise rather than clarity. For a sequenced framework that organizes these resources into a repeatable process, the 137Foundry vendor evaluation guide is a practical starting point.

Step-by-Step Webhook Signature Verification for Any Sender

137Foundry — Fri, 24 Apr 2026 11:15:03 +0000

Webhook signature verification is the first line of defense against forged events. Without it, any HTTP client that knows your endpoint URL can POST fabricated events. The verification process is the same across most webhook senders, even when the specific header names and hash algorithms differ.

This guide walks through implementing signature verification for a webhook receiver, from parsing the header to computing the HMAC to returning the right response.

Step 1: Get the Raw Request Body Before Any Parsing

This is the step most implementations get wrong. Signature verification computes an HMAC over the raw request body bytes. The HMAC must be computed before any framework deserialization happens.

Web frameworks parse JSON bodies automatically. When they do, they may normalize whitespace, change encoding, or reorder keys. Computing the HMAC over the parsed-then-re-serialized body will produce a different hash than the sender computed over the original bytes. The verification will fail even for valid payloads.

In Python with FastAPI:

from fastapi import Request

@app.post("/webhooks/events")
async def receive_webhook(request: Request):
    raw_body = await request.body()  # raw bytes, before any JSON parsing
    signature = request.headers.get("X-Signature-256", "")
    # verify against raw_body, not json.loads(raw_body)

In Node.js with Express:

app.post('/webhooks/events', express.raw({ type: 'application/json' }), (req, res) => {
  const rawBody = req.body;  // Buffer, not parsed JSON
  const signature = req.headers['x-signature-256'];
  // verify against rawBody
});

The express.raw() middleware captures the body as a Buffer instead of parsing it. Without it, req.body contains the parsed JSON object, which breaks verification.

Step 2: Parse the Signature Header

Webhook senders typically include both the HMAC hash and a timestamp in the signature header, either as separate headers or combined in a single header. Stripe combines them in a single header with a specific format:

Stripe-Signature: t=1714000000,v1=abc123...

Parse the header to extract the timestamp and the hash:

def parse_stripe_signature(header: str) -> dict:
    parts = {}
    for part in header.split(","):
        key, value = part.split("=", 1)
        parts[key] = value
    return parts

sig_parts = parse_stripe_signature(request.headers.get("Stripe-Signature", ""))
timestamp = sig_parts.get("t", "")
received_hash = sig_parts.get("v1", "")

Other senders use a simpler format with the hash prefixed:

X-Signature-256: sha256=abc123...

received_hash = signature_header.removeprefix("sha256=")

Check the sender's documentation for their specific header format. The concept is the same; only the parsing differs.

Step 3: Compute the Expected HMAC

With the raw body bytes and the shared secret, compute the expected HMAC using the algorithm your sender specifies. Most use SHA-256.

For Stripe-style signatures where the hash is computed over {timestamp}.{body}:

import hmac
import hashlib

def compute_hmac(raw_body: bytes, timestamp: str, secret: str) -> str:
    signed_payload = f"{timestamp}.".encode() + raw_body
    return hmac.new(
        secret.encode(),
        signed_payload,
        hashlib.sha256
    ).hexdigest()

For simpler senders where the hash is computed directly over the body:

def compute_hmac_simple(raw_body: bytes, secret: str) -> str:
    return hmac.new(
        secret.encode(),
        raw_body,
        hashlib.sha256
    ).hexdigest()

Step 4: Compare Using Constant-Time Equality

Never use == to compare the expected and received hashes. Standard string equality short-circuits on the first differing character, which creates a timing side channel. An attacker can measure how long the comparison takes to determine how many leading characters of the hash they got right, eventually reconstructing a valid hash without knowing the secret.

is_valid = hmac.compare_digest(expected_hash, received_hash)

hmac.compare_digest takes the same amount of time regardless of where the strings differ. The equivalent in JavaScript uses the crypto module's timingSafeEqual function.

Step 5: Check the Timestamp Window

If the sender includes a timestamp in the signature header, check that it's within an acceptable window (typically five minutes). This prevents replay attacks where an attacker captures a valid signed request and re-sends it later.

import time

def is_timestamp_valid(timestamp: str, max_age_seconds: int = 300) -> bool:
    try:
        event_time = int(timestamp)
        return abs(time.time() - event_time) < max_age_seconds
    except (ValueError, TypeError):
        return False

If the timestamp is more than five minutes old, return 400 and log the event for investigation. The sender should not be sending payloads with stale timestamps; this is a potential replay attempt.

Step 6: Return the Right Status Codes

The response status code tells the sender whether to retry:

200: Event received and accepted. Don't retry.
400: Invalid signature or malformed request. Don't retry (retries won't fix a tampered payload).
500: Server error. Retry according to retry policy.

Return 400 on signature failures, not 500. A 500 tells the sender to retry, which is wrong behavior for a forged payload. A 400 tells the sender the request was rejected as invalid.

Testing the Verification Logic

The most important tests to write:

Valid signature passes verification
Tampered body fails verification
Wrong secret fails verification
Missing signature header returns 400
Expired timestamp is rejected

Use Postman to send test requests with custom signature headers to a running server. ngrok lets you test against a real external sender during development.

Handling Senders That Deviate from the Standard Pattern

Not all webhook senders follow the same verification scheme. Most use HMAC-SHA256 with a shared secret, but the payload construction, header format, and timestamp handling vary.

Timestamp in the signed payload. Stripe constructs the signed payload as {timestamp}.{raw_body}, not just the raw body. This means you need to extract the timestamp from the signature header, construct the signed string manually before computing the HMAC, and verify that string against the received hash. A receiver that computes the HMAC over just the raw body will fail verification for Stripe webhooks even if the secret is correct.

Multiple hash versions. Some senders include multiple hash versions in the header (for example, both a v0 and v1 hash). The receiver should check whether any of the provided hashes matches the expected value, rather than requiring a specific version. This allows the sender to rotate their signing scheme without breaking receivers.

No timestamp. Some simpler webhook senders include only the HMAC hash with no timestamp. For these, timestamp validation isn't possible, but you should still verify the HMAC. The absence of a timestamp means replay attacks are technically possible, which is worth noting in your integration documentation.

Custom algorithms. A small number of senders use HMAC-SHA1 instead of SHA256. HMAC-SHA1 is not considered broken for this use case, but SHA256 is preferred. Implement the algorithm your specific sender specifies.

Common Verification Failures in Production

A few signature verification failures that appear consistently across production webhook integrations:

Middleware that reads the body. Some logging middleware or request parsing middleware reads the request body before your verification code runs. If the body is consumed and not replaced with the original bytes, your verification code gets an empty body. Make sure any body-reading middleware restores the raw bytes before the request reaches the webhook handler.

Content-Type normalization. Some frameworks normalize or re-parse the body when the Content-Type header is application/json. Using express.raw() or the framework-equivalent prevents this. Always test signature verification explicitly in your actual framework environment, not just in isolation.

Header name case sensitivity. HTTP header names are case-insensitive by spec but some implementations are not. If your verification code looks for X-Signature-256 but the sender sends x-signature-256, some frameworks will pass it through and some won't. Use case-insensitive header lookup.

For the broader receiver architecture (async processing, idempotency, failure handling), How to Build a Webhook Receiver That Handles Real-World Traffic covers how signature verification fits into the complete pattern.

This development service builds and maintains data integration infrastructure including webhook receivers, event processors, and API integrations for production workloads.

Photo by Hans on Pixabay

Why Synchronous Webhook Processing Is a Production Trap

137Foundry — Fri, 24 Apr 2026 11:15:00 +0000

Most webhook implementations start the same way: the event arrives, the handler parses the payload, does some database work, maybe fires an email, and returns 200. It works in testing. It works in early production with low event volumes. Then it fails in predictable and expensive ways.

The failure modes of synchronous webhook processing are not edge cases. They're the normal operating conditions of a production webhook integration. Understanding why they fail makes the fix obvious.

What Synchronous Processing Looks Like

A synchronous webhook handler processes the event in the same request context where it was received. In pseudocode:

POST /webhooks/events
  1. Parse payload
  2. Verify signature
  3. Query database to get account
  4. Update account records
  5. Send confirmation email
  6. Return 200

Steps 3, 4, and 5 involve external calls. A database query under load might take 500ms. An email provider having a slow day might take 2 seconds. If anything in steps 3-5 throws an exception, the handler returns a 500.

The Retry Problem

Most webhook senders interpret a non-2xx response as delivery failure and schedule a retry. Stripe retries webhooks for up to three days, with increasing intervals between attempts. GitHub retries delivery failures. Most enterprise webhook senders follow a similar policy.

When your synchronous handler returns 500 because the database query timed out, the sender queues a retry. The retry arrives, your database is still under load, and returns 500 again. After several retries, you have a queue of the same event being retried repeatedly, each attempt potentially writing partial state to the database before failing.

The synchronous handler created a worst-case scenario: the database is slow, so the handler fails, so there are more retries, so the database load increases. This is a feedback loop.

The Timeout Problem

Webhook senders enforce delivery timeouts. If your endpoint doesn't respond within their timeout window (often 5-30 seconds), they treat it as a failed delivery and schedule a retry.

For most simple operations, this isn't a problem. For operations that involve slow downstream services, it is. A third-party API call that normally completes in 1 second might take 15 seconds under load. Your handler, waiting for that call to complete, times out from the sender's perspective before returning a response. The sender retries. You now have the same event being processed twice simultaneously, each racing to write to the same database records.

The Idempotency Problem That Synchronous Processing Creates

Synchronous processing combined with retries creates idempotency problems in code that was never designed to handle duplicate events. If your handler does:

account.credits += event.amount
account.save()

Running this twice doubles the credit amount. Running it once is correct. Designing for exactly-once execution is hard when you can't guarantee the sender won't retry.

Idempotent processing (checking whether an event ID has already been handled before doing any work) is the correct solution. But tacking it onto a synchronous handler doesn't fix the underlying architecture problem. You're still doing work inside the request window, still subject to timeouts, and still returning 500s on failures that cause retries.

The Correct Architecture Separates Receiving from Processing

The fix is to separate what happens in the request from what happens after it. The receiver endpoint does three things: verify the signature, store the raw payload, and return 200. Everything else happens in a background worker after the request has been acknowledged.

POST /webhooks/events
  1. Verify signature -> 400 if invalid
  2. Check idempotency (event_id already seen?) -> 200 immediately
  3. Write raw payload to queue with status "pending"
  4. Return 200

[background worker]
  1. Read "pending" event from queue
  2. Process event (queries, updates, notifications)
  3. Mark event as "processed" or "failed"

The receiver now completes in under 500 milliseconds regardless of what processing involves. The sender gets a 200 immediately after delivery. Retries only happen if the network connection fails before the response, not because processing was slow.

What the Worker Gets

The worker processes events asynchronously, which changes what's possible. Retrying failed events is now the worker's responsibility, not the sender's. If a database is slow, the worker backs off and retries with exponential delay. If a downstream service is down, the event stays in the queue until it becomes available. No 500s, no sender retries, no feedback loops.

Redis works well as the queue layer for this pattern. The receiver appends events to a list or stream. Workers consume from the stream, update event status on completion, and move failed events to a dead-letter queue after exhausting retries.

Designing Worker Retry Logic

The worker's retry behavior matters as much as the receiver's architecture. Without explicit retry logic, a single transient failure leaves the event in a failed state permanently.

A practical worker retry pattern:

Pick up the event and attempt processing.
On success, mark the event as "processed" with a completion timestamp.
On failure, increment a retry count. If below the threshold, return the event to the queue with an exponential delay. If the retry count exceeds the threshold, move the event to a dead-letter queue and emit an alert.

The delay between retries should grow with each attempt. Flat retry intervals put sustained pressure on a downstream service that's already struggling. Exponential backoff -- retry after 10 seconds, then 100, then 1000 -- gives external services time to recover without exhausting retries immediately. Most production systems cap the maximum interval to avoid events sitting in the queue indefinitely.

Queue infrastructure handles much of this natively. Redis streams track unacknowledged messages and allow a configurable pending timeout before re-delivery. RabbitMQ's dead-letter exchange can route a message to a retry queue with a delay after a configurable rejection count.

Dead-Letter Queue Design

Events that exhaust their retry limit need a place to go that isn't silently deleted. A dead-letter queue preserves events that couldn't be processed after multiple attempts, making them available for inspection and manual replay.

The minimum useful dead-letter record includes: the original payload, the event source, the retry count, the last error message, and the timestamp of the last attempt. The error message is critical -- without it, debugging what went wrong requires reconstructing the failure from distributed application logs, which is much slower.

Dead-letter management can be straightforward. A separate database table, a query to list failed events by source and time range, and a replay operation that resets a set of events back to "pending" covers most operational needs. The engineering work is in setting up an alert when dead-letter depth grows past a threshold so the failures are visible before they affect business-critical event types.

Testing the full async flow end-to-end during development is important. Unit tests verify the processing logic in isolation, but they can't replicate the sender's retry timing or the behavior of the real queue consumer. ngrok exposes your local receiver to the actual external sender so you can exercise the complete path including signature verification, queue writes, and worker consumption under realistic delivery conditions.

When the Synchronous Approach Is Acceptable

For very simple processing (a webhook that only logs the event to a table) and very small volumes, synchronous processing is fine. The failure modes described here only manifest at meaningful event volumes or when processing involves slow external calls.

For a complete implementation of the async receiver pattern including signature verification, idempotency, and failure handling, How to Build a Webhook Receiver That Handles Real-World Traffic covers each component with implementation notes.

This team at 137Foundry builds data integration infrastructure, including webhook receivers for high-volume event processing environments.

Photo by delphinmedia on Pixabay

7 Free UX Tools for Researching and Testing Web Form Design

137Foundry — Thu, 23 Apr 2026 15:30:19 +0000

Designing better forms requires data about how users interact with them. These seven tools help with different parts of that process: understanding where forms fail, testing how users experience them, checking accessibility, and researching what evidence-based form design looks like across products and contexts. All have a meaningful free tier.

1. Microsoft Clarity

Microsoft Clarity is a free behavioral analytics tool that records user sessions and generates heatmaps of click, scroll, and interaction patterns. For form design, the session recording feature is particularly valuable: you can watch how users interact with specific form fields, where they pause, which fields they re-enter, and at which point they abandon the form.

Clarity's "rage click" and "dead click" detection automatically flags interactions where users appear frustrated (rapid repeated clicks) or where clicks are not triggering expected responses. Both of these patterns frequently appear in form interaction data and can surface problems with small touch targets, confusing validation states, and non-interactive-looking submit buttons.

The session recording capability does not capture personally identifiable information or form field contents by default, which makes it safer to use on forms without additional configuration. The free tier includes unlimited session recordings and heatmaps.

2. Google Analytics 4 (with Event Tracking)

Google Analytics 4 tracks user behavior across your site and can be configured with custom events to measure form-specific metrics: how many users viewed a form, how many started it, how many completed it, and what percentage abandoned at each step of a multi-step form.

The funnel analysis feature in GA4 allows you to define a sequence of steps and see the dropout rate at each point. For multi-step forms, this reveals exactly which step drives the most abandonment. For single-page forms with multiple fields, field-level events require manual event implementation, but the resulting data is highly specific to your actual form and users.

GA4 is free at standard traffic volumes. The event tracking setup for forms requires some JavaScript implementation, but the payoff in diagnostic specificity is significant.

3. Maze (Free Tier)

Maze is an unmoderated user testing platform that lets you create tasks for users to complete, including filling out a prototype or live form, and then analyzes where users get stuck or fail. The free tier includes a limited number of tests per month and access to the core path and mission metrics.

For form testing, Maze is useful for discovering usability problems before launch by having representative users attempt to complete the form while recording where they hesitate, fail, or succeed. The platform aggregates results across multiple participants and shows paths through the form as a visual flow.

The unmoderated format means testing can happen asynchronously without requiring you to be present, which makes it practical to run a quick test before shipping a form change.

For the principles behind what these tools help you identify, the guide at 137foundry.com/articles/how-to-design-web-forms-users-complete covers validation patterns, field count, mobile layout, and error message design in detail.

4. WAVE Accessibility Checker

WebAIM produces WAVE, a browser-based accessibility evaluation tool that checks web pages including forms for accessibility errors and warnings. Running WAVE on a form reveals missing labels, insufficient color contrast, unlabeled form controls, and missing ARIA attributes that would make the form inaccessible to users of assistive technology.

The browser extension version evaluates pages in their current state, including dynamic states like validation errors, which makes it more useful for form accessibility testing than crawling-based tools that only see the initial page state.

WAVE is free as both a browser extension and a web-based tool. For teams embedding accessibility checks in a development workflow, the API version allows automated scanning as part of a CI pipeline.

5. Axe DevTools (Free Browser Extension)

The axe DevTools browser extension from Deque Systems performs automated accessibility audits on web pages. Like WAVE, it identifies accessibility violations and provides specific guidance on how to fix them.

Where axe differentiates itself for development teams is in its integration with the browser DevTools panel, making it easy to inspect specific elements alongside their accessibility issues. The extension is built on the same axe-core rules used by tools like Jest-axe and Playwright's accessibility testing APIs, which means issues found in browser testing with axe are consistent with what automated testing will catch.

The free extension covers a substantial portion of WCAG 2.1 violations. The paid DevTools Pro version adds guided testing and more comprehensive rule sets.

6. The A11y Project Checklist

The A11y Project maintains a comprehensive checklist of web accessibility requirements organized by WCAG criteria. For form design specifically, the checklist covers labels, error identification, keyboard navigation, focus management, and timeout notifications, all in plain language that is more actionable than reading the WCAG specification directly.

This is a reference tool rather than a testing tool, but using it as a design checklist before building a form reduces the number of accessibility fixes required after testing. It is particularly useful for designers and developers who are not accessibility specialists and need a clear, prioritized list of what to check.

7. Nielsen Norman Group Research Reports (Free Articles)

The Nielsen Norman Group makes a substantial portion of its UX research findings freely available in article form. For form design, the NNG article archive covers field ordering, label placement, error message design, mobile form patterns, multi-step form design, and checkout UX in detail backed by usability studies.

While the full research reports require a subscription or purchase, the free articles provide enough evidence-based guidance to inform most form design decisions. Searching the NNG archive for "form design" or "form usability" returns a large set of relevant articles that can be used as a reference layer alongside your own testing data.

Photo by Pexels on Pixabay

How These Tools Work Together

Using these tools together covers the full form design and validation cycle. Clarity and Google Analytics provide behavioral data from real users on your live forms. Maze lets you test with representative users before or alongside launch. WAVE and Axe check accessibility compliance at the implementation level. The A11y Project gives you a reference checklist for design decisions. NNG research provides the evidence base for why certain patterns work and others do not.

UX and web studio 137Foundry builds and tests forms as part of broader web design and development projects. The web development services page describes how form design and UX testing fit into our project process.

The World Wide Web Consortium maintains the WCAG accessibility standards that WAVE, Axe, and the A11y Project checklist are built around, and provides the authoritative reference for understanding accessibility requirements at a specification level.

The most effective approach to form improvement combines at least two of these tools: one that provides behavioral data from real users (Clarity, GA4) and one that provides a way to understand the why behind that behavior (Maze user testing, NNG research). Behavioral data tells you where users stop. User testing and research tell you why. Acting on behavioral data without understanding why the abandonment is happening can lead to fixing symptoms rather than the underlying design problem. The combination of quantitative data and qualitative insight is what produces form improvements that hold up over time rather than winning a single A/B test and then plateauing.

How Inline Validation Reduces Form Abandonment and Errors

137Foundry — Thu, 23 Apr 2026 15:28:31 +0000

Form validation is one of the most consequential UX decisions in web development. The same set of validation rules, implemented with two different timing strategies, can produce meaningfully different completion rates. Inline validation, where feedback appears field-by-field as users progress through a form, consistently outperforms submit-and-validate-all patterns for user experience and completion.

This article covers how inline validation works, when to use it, how to implement it correctly, and the specific patterns that make it effective versus counterproductive.

Why Submit-Time Validation Creates a Poor Experience

The traditional validation pattern, validate all fields when the user clicks submit, creates several compounding problems.

Error discovery is deferred. The user completes the entire form before learning anything is wrong. At that point they have the most invested in the task and the most to lose psychologically if they have to redo work.

Error location requires searching. Validation errors returned after submit are typically shown at the top of the form or highlighted inline, but the user must scroll back through the form to find each highlighted field. On a long form, this requires significant navigation. On mobile, it can feel like starting over.

Multiple errors appear simultaneously. When several fields fail validation at once, users face a list of errors to work through. Each one requires re-reading the instructions, locating the field, and correcting it. The cognitive and emotional cost compounds.

False success signals occur. A user who fills in a field incorrectly but receives no feedback until submitting believes the field is fine until the error appears. The correction feels like a reversal rather than a natural part of the process.

What Inline Validation Changes

Inline validation checks each field individually after the user leaves it (on blur). Feedback appears immediately below the field while the user is still in the context of that section of the form. Errors are corrected one at a time, at the moment of lowest cost.

The research on this is consistent. A landmark study by the Interaction Design Foundation and subsequent replications found that inline validation reduced errors by 22%, reduced completion time by 42%, and increased satisfaction scores compared to after-submit validation for the same form content. The gains are largest for long forms and forms with complex field requirements.

Web design agency 137Foundry implements inline validation as the default validation pattern on forms built for client projects. The principle is covered in our broader form design guide at 137foundry.com/articles/how-to-design-web-forms-users-complete, which covers field count, input types, mobile layout, and confirmation experience alongside validation strategy.

The Critical Implementation Detail: Validate on Blur, Not on Input

The most common inline validation mistake is triggering validation while the user is still typing (on the input event). This produces false errors constantly.

An email field checked on input will show "invalid email" the moment the user types a single character. A user who has not yet typed the @ symbol is not making an error; they are in the middle of typing. Checking at this point creates visual noise and anxiety without providing useful feedback.

The correct event to validate on is blur, which fires when the user moves focus out of the field. At that point, the user has finished entering their input and validation feedback is appropriate and timely.

document.querySelector('#email').addEventListener('blur', function () {
  validateField(this);
});

For confirm-password or interdependent fields where one field's validity depends on another's value, you may need to re-validate one field when the other changes. For example, confirming that a "confirm password" field matches the password field should re-run when either field changes.

const password = document.querySelector('#password');
const confirm = document.querySelector('#confirm-password');

confirm.addEventListener('blur', () => validateMatch(password, confirm));
password.addEventListener('blur', () => {
  if (confirm.value) validateMatch(password, confirm);
});

Error Message Placement and Content

Error messages should appear immediately below the field they describe, in the reading flow between the field and the next element. They should be visible without scrolling, associated with the field via aria-describedby for screen reader accessibility, and dismissed automatically when the user corrects the error.

Message content should be specific about what is wrong and what the correct format is:

<label for="phone">Phone number</label>
<input
  type="tel"
  id="phone"
  aria-describedby="phone-error"
  aria-invalid="true"
/>
<p id="phone-error" role="alert">
  Enter a phone number with 10 digits, like 5551234567
</p>

The aria-invalid="true" attribute signals to screen readers that the field has an error. The role="alert" on the error paragraph causes screen readers to announce the message when it appears, without requiring the user to navigate to it. The Mozilla Developer Network provides the full reference for ARIA form patterns, and the Web Accessibility Initiative documents the accessibility requirements for form error identification.

Visual Design of Inline Validation States

Each field should have three visible states beyond the default: active/focused, valid, and error.

Active/focused: A clear focus ring that meets WCAG 2.1 contrast requirements. Do not remove the native focus ring without providing a visible alternative.

Valid: A subtle success indicator, typically a green checkmark or border color change, that appears when the user leaves a field after entering acceptable input. Keep this understated; a form that aggressively celebrates each correct field becomes noisy.

Error: A red border, error icon, and the error message. Red should not be the only indicator (for color-blind users); combine it with an icon and the text message.

Avoid using placeholder text to communicate required format or examples. Placeholder text disappears when the user starts typing, which means they cannot reference it if they are unsure what to enter. Visible hint text below the label, present before the user interacts with the field, is the correct pattern.

Testing Inline Validation With Automated Tools

Inline validation introduces dynamic content changes to the DOM, which means your standard HTML validation pass may not catch all issues. Testing should cover:

Keyboard navigation: Tab through all fields and verify that error messages appear and are announced correctly without requiring a mouse.
Screen reader testing: Use NVDA (on Windows) or VoiceOver (on macOS and iOS) to verify that errors are announced at the right moment and associated correctly with their fields.
Automated accessibility checks: Tools like Axe (from deque.com) and the built-in browser DevTools accessibility panel catch missing ARIA attributes, insufficient color contrast, and unlabeled fields.

// Example: programmatically triggering validation for testing
function runValidationTests() {
  const fields = document.querySelectorAll('[data-validate]');
  fields.forEach(field => {
    field.dispatchEvent(new Event('blur'));
  });
}

The A11y Project maintains a checklist that covers the accessibility requirements for form validation states. WebAIM provides additional documentation on accessible form design and testing approaches.

When to Show Positive Confirmation

Not every field needs a success state. For fields where the validity criteria are simple and familiar (email, phone number, date), a success indicator after the user leaves the field provides reassurance that the input was accepted. For fields with complex or unusual requirements (password strength, specific numeric ranges), the success state after validation is more valuable because it confirms that the requirements were met.

For password fields, showing strength feedback while the user is typing (on the input event) is one of the few legitimate exceptions to the blur-validation rule, because the feedback is progressive and genuinely useful during input, not a false error.

password.addEventListener('input', function () {
  updateStrengthMeter(this.value);
});

The Nielsen Norman Group has published specific research on password field design and strength meter usability that provides useful reference for this specific case.

Summary

Inline validation on the blur event, with specific error messages, correct ARIA attributes, and clear visual states, is consistently better than submit-time validation for both users and completion rates. The implementation is straightforward in vanilla JavaScript and can be adapted to any front-end framework. The gains in completion rate, user satisfaction, and error reduction are well-documented and reliably reproducible by applying the pattern correctly.

For the broader context on how validation fits into a complete form UX strategy, the 137Foundry services page covers the web design and development work where these patterns are applied in production.

7 Free Tools for Testing and Analyzing HTTP Caching Behavior

137Foundry — Wed, 22 Apr 2026 11:15:31 +0000

Getting HTTP caching right is mostly a matter of setting the correct headers. But knowing whether you set them correctly requires being able to inspect actual response headers, simulate cache behavior, and verify that resources are being cached and invalidated the way you intend.

These seven tools let you do that without paying for anything. They cover browser-level inspection, command-line header analysis, performance auditing, and CDN-layer caching behavior.

1. Chrome DevTools Network Panel

Chrome DevTools is the fastest way to inspect cache headers for any resource a page loads. Open the Network panel, load a page with cache disabled, and click any request to see its response headers.

The panel shows Cache-Control, ETag, Last-Modified, Expires, and Vary headers directly. On subsequent loads, the Size column displays "disk cache" or "memory cache" for resources served from cache. The status column shows 304 for revalidated resources.

The Lighthouse tab in DevTools includes a "Serve static assets with an efficient cache policy" audit that lists every resource with a TTL under one week and estimates the bandwidth savings from extending it.

This should be the first tool in any caching audit workflow.

2. curl

curl is the most reliable way to inspect HTTP headers from the command line. It makes actual HTTP requests to your server or CDN and displays the raw response headers.

To see just the response headers without downloading the body:

curl -I https://example.com

To follow redirects and see all response headers along the way:

curl -IL https://example.com/

The -I flag sends a HEAD request. For resources where HEAD behaves differently from GET, use -X GET --head instead.

curl is particularly useful for checking how your CDN modifies cache headers relative to what your origin server sends. Run the same command against the CDN URL and the origin URL directly and compare the output. Differences between the two often explain why a resource appears to cache correctly at the origin but fails to cache at the edge.

3. WebPageTest

WebPageTest is a free, open-source performance testing tool that runs synthetic tests from multiple geographic locations. It measures real page load times including the effect of caching on repeat visits.

The "Repeat View" feature runs the same test twice: once for a first-time visitor and once for a returning visitor who has cached resources. The difference between the two load times tells you how much your current cache configuration is helping for repeat visitors.

WebPageTest also produces a waterfall chart that shows when each resource was requested, whether it was cached, and what the response headers contained. This is useful for identifying resources that should be cached but are not.

4. PageSpeed Insights

PageSpeed Insights is Google's free performance analysis tool that runs Lighthouse audits against any public URL. Its "Serve static assets with an efficient cache policy" audit surfaces resources with short or missing cache TTLs and estimates the bandwidth savings from extending them.

Because PageSpeed Insights runs Lighthouse server-side, results are consistent and reproducible regardless of which device or browser you are testing from. This makes it useful for confirming that a cache configuration change had the intended effect after deployment without relying on local browser state.

The tool separates lab data from field data. Lab data shows what Lighthouse measured in a controlled test run. Field data draws from the Chrome User Experience Report, giving you a sense of real-world caching performance across actual user visits. For cache header auditing, the lab data section is most directly relevant because it shows exactly which headers each resource returned during the test. For teams that ship frequently, running PageSpeed Insights against a production URL after each deployment is a low-cost check that cache header regressions have not crept in through new asset types or updated server configurations. The audit output names each offending resource alongside its current TTL and a recommended minimum, which maps directly to the Cache-Control directives you need to adjust.

5. Redbot

Redbot is a purpose-built HTTP header analysis tool maintained by the HTTP working group community. You enter a URL and it fetches the resource and analyzes the response headers in detail, explaining what each directive means and flagging problems.

Redbot explains why a header is or is not correct, not just whether it is present. For developers learning caching behavior, this explanatory output is more useful than a binary pass/fail.

It checks Cache-Control, ETag, Last-Modified, Vary, Content-Encoding, and several other headers, and it follows redirects to check the headers at the final destination.

6. Fastly's Cache Simulator

Fastly provides a free cache behavior simulator as part of their developer documentation. It lets you input response headers and see how a CDN interprets them, including which directives control what behavior at the shared cache layer.

While Fastly is a paid CDN service, the simulator itself is free and useful for understanding CDN-specific behavior independently of which CDN you actually use. Different CDNs have different default behaviors for responses without explicit public directives or for responses that include Set-Cookie headers.

The simulator is particularly useful for verifying how s-maxage and stale-while-revalidate behave at the CDN layer before you deploy.

"The most common caching audit finding we see is long-lived HTML pages referencing short-lived assets. Two header changes fix the whole pattern." - Dennis Traina, founder of 137Foundry

7. Nginx Logs With Cache Hit Analysis

If you are running Nginx as a reverse proxy or CDN equivalent, its proxy cache module logs include a $upstream_cache_status variable that reports whether each request was a HIT, MISS, BYPASS, or EXPIRED in the cache.

Adding this variable to your access log format gives you a real-time cache hit rate breakdown without any additional tooling:

log_format cache_log '$remote_addr - $upstream_cache_status - "$request" $status';
access_log /var/log/nginx/cache.log cache_log;

After collecting a few thousand requests, parsing the log for cache status gives you a practical hit rate for each URL pattern. A consistently low hit rate on resources that should be cacheable points to a configuration problem.

This approach works for any Nginx-based cache, including Nginx configured as a local caching proxy in front of a Node.js or Python application.

How to Use These Tools Together

A typical caching audit workflow:

Use Chrome DevTools to identify resources with missing or short Cache-Control headers
Verify the exact headers with curl from the command line to confirm what the CDN is passing through
Run WebPageTest or GTmetrix to see the repeat-visit improvement from fixing the headers
Use Redbot on individual URLs to get detailed explanations for anything unclear
Use Nginx logs or Fastly's simulator to verify CDN-layer behavior

The audit is iterative rather than one-time. New resources added after a deployment often inherit whatever default header configuration is in place, which may not match the correct TTL for their type. Reviewing caching headers after each major deployment is a low-effort way to catch these regressions before they compound into a significant performance difference. Automating the check with curl against a known resource list as part of your deployment verification process eliminates the need for manual audits in the first place.

For a deeper look at the caching patterns behind these checks, the article HTTP Caching: A Practical Guide for Web Developers covers the strategy behind what the tools surface. 137Foundry includes caching configuration as a standard part of web application delivery. MDN's HTTP caching documentation provides the canonical reference for every header and directive these tools analyze.

Photo by svetlana photographer on Pexels

How HTTP Caching Works at the Browser, CDN, and Proxy Layer

137Foundry — Wed, 22 Apr 2026 11:09:56 +0000

HTTP caching is not one thing. It is a set of behaviors that happen at different layers of the network stack, each governed by the same response headers but producing different effects depending on which layer is doing the caching.

Understanding each layer separately makes it much easier to diagnose caching problems, because a bug that looks like "the browser is not caching this" is often actually "the CDN is stripping the header before it reaches the browser." Treating all caching as one system obscures the actual source of the problem.

The Three Cache Layers

A typical web request passes through three caches on its way from origin server to user.

The browser cache is local to the user's device. It stores responses that the server marks as cacheable, keyed by URL. Subsequent requests for the same URL check this cache first. If the stored response is still fresh, the request never leaves the device.

The CDN edge cache is a shared cache maintained by your CDN provider at geographic nodes distributed around the world. When a user requests a resource, the CDN node closest to them checks whether it has a cached copy. If it does, it serves the response directly. If not, it fetches from the origin and caches the response for future requests in that region.

Intermediate proxies sit between the user and the CDN, or between the CDN and origin, depending on network topology. Corporate networks often include forward proxies that cache responses on behalf of internal users. These proxies also consult Cache-Control directives.

How Freshness Works

A cached response has a lifetime. The server signals how long the response should be considered fresh via the max-age directive in the Cache-Control header.

Cache-Control: max-age=3600 means the response is fresh for 3,600 seconds after it was received. During that window, caches at any layer can serve the stored response without consulting the server.

After the window expires, the response is stale. A stale response can still be served in some cases, but the cache should attempt to revalidate it first. Revalidation sends a conditional request to the server: "I have this response from earlier. Has anything changed?"

The server responds either with 304 Not Modified, which means the cached copy is still valid and can be served, or with a full 200 OK response containing the updated content.

Freshness applies independently at each cache layer. A browser cache entry might expire before a CDN cache entry for the same resource, or vice versa, depending on how long the resource has been cached at each layer.

How the Browser Cache Decides What to Store

The browser caches a response if the response headers permit it. The decision involves several rules:

The request method must be GET or HEAD. POST responses are not cached.
The response status must be cacheable (200, 301, 302, 404, and a few others are cacheable by default).
The response must not include Cache-Control: no-store.
If Cache-Control: private is present, the response is cached only in the browser, not in shared caches.
If no Cache-Control header is present, the browser may cache heuristically based on Last-Modified.

When a cached response becomes stale, the browser sends a conditional request. If the response included an ETag header, the browser sends If-None-Match: "etag-value". If the response included Last-Modified, the browser sends If-Modified-Since: timestamp. The server responds with 304 if the resource has not changed, allowing the browser to extend the life of its cached copy.

Photo by Markus Spiske on Pexels

How the CDN Cache Differs From the Browser Cache

CDN caches are shared: they store responses that are served to many different users. This introduces considerations that browser caches do not have.

Personalization. The CDN must not store responses that differ by user. Cache-Control: private tells CDNs to skip the response. Without this directive, a CDN might cache a personalized response and serve it to the wrong user.

Cache keys. CDNs cache by URL by default. If a response varies by request header (e.g., different responses for mobile vs. desktop based on User-Agent), the Vary header must be included so the CDN stores separate entries.

TTL differentiation. s-maxage lets you specify a TTL for shared caches independently of the browser TTL. Cache-Control: max-age=60, s-maxage=3600 gives the browser a 1-minute freshness window and the CDN a 1-hour window. This pattern is useful for resources where you want the CDN to cache aggressively but the browser to check for updates more often.

Purging. Unlike browser caches, CDN caches can be cleared server-side. Most CDNs offer an API to purge cached entries by URL, path prefix, or tag. This enables cache invalidation as part of a deployment pipeline.

How Intermediate Proxies Behave

Intermediate proxies follow the same HTTP caching spec as CDNs. They respect Cache-Control: private to avoid storing personalized responses, and they honor no-store to skip caching entirely.

The main practical difference is that you typically cannot predict which proxies a request might pass through, and you cannot purge their caches. A corporate proxy that caches a response with a long TTL will continue serving that response until the TTL expires, regardless of what happens on your origin.

The Cache-Control: no-cache directive is useful here. It allows responses to be stored in intermediate caches but requires revalidation before serving. This means even a proxy that has cached the response for a long time will check with the server before serving it to a new request.

How Service Workers Interact With HTTP Caching

Service workers add a programmable cache layer between the browser and the network. They can intercept fetch requests, serve responses from their own cache, and bypass HTTP caching entirely.

A service worker's cache is independent of the browser's HTTP cache. A resource cached by a service worker may be served even when the HTTP cache would have revalidated or rejected the cached copy.

This means HTTP caching behavior and service worker behavior can conflict. If you are debugging a caching issue in an application that uses a service worker, check whether the service worker is intercepting the request before checking the HTTP cache configuration.

Photo by Brett Sayles on Pexels

The Practical Takeaway

Each cache layer operates independently but responds to the same response headers. Cache-Control is the single header that controls all of them, with directives that target different layers specifically.

The most reliable approach to multi-layer caching:

Use public, max-age=31536000, immutable for static assets with content-addressed URLs
Use no-cache for HTML pages so browsers revalidate but CDN caches work with short TTLs
Use private, no-store for personalized API responses
Use s-maxage to differentiate CDN and browser TTLs when needed
Add Vary for any response where content differs by request header

For more detail on how these directives interact with CDN behavior and deployment workflows, 137Foundry covers caching configuration as part of web application delivery at our services page. The full article HTTP Caching: A Practical Guide for Web Developers covers each directive in depth. The HTTP caching RFC at the IETF is the authoritative specification if you need to resolve ambiguous behavior. Google's web.dev caching guide is the most accessible reference for practical application. For CDN-specific caching behavior and how edge nodes modify response headers, Cloudflare's caching documentation is the most detailed public reference for a widely deployed CDN.

Photo by Daniil Komov on Pexels