Http Failure Status 0: Angular Network Fix

Your service call fails with Http failure response for (unknown url): 0 Unknown Error. No status code, no body, no endpoint name. The backend team says their logs are clean. Your code looks correct. Everyone stares at each other.

Status 0 is Angular telling you there was never an HTTP response to report. The browser blocked the request or the network dropped it before any server answered: a CORS preflight the server rejected, a backend that was down, a laptop that went offline, an adblocker that ate the URL, or an HTTPS page calling an HTTP API. Your application code didn't fail; it never got to play.

This distinction decides the whole debugging strategy. Application bugs reproduce in logic; network failures reproduce in the Network tab. Developers who start in the component waste hours reviewing interceptors for a request the browser never sent.

This guide teaches the network-first workflow. You'll learn what status 0 actually means, how to read the Network tab for each cause, why CORS failures can't be fixed from Angular, how adblockers and mixed content ambush production, and how to build retry and offline handling that treats zeros as expected weather.

What Status 0 Actually Means

Angular wraps every HTTP failure in HttpErrorResponse, and status 0 is its way of saying the HTTP layer never completed. Real statuses like 404 or 500 arrive with response headers, bodies, and timing; status 0 arrives with the statusText Unknown Error and a null body because nothing arrived at all. The url field may even read unknown when the browser blocked the request before resolving it. Reading this shape correctly prevents the entire category of misdiagnosis where teams tune backend queries for a request the backend never saw.

The five causes cover nearly every report. CORS preflight rejection kills cross-origin requests at the browser's door. Server downtime or DNS failure leaves the connection with nothing to answer. Client offline states, from airplane mode to dead office Wi-Fi, produce zeros indistinguishable from outages without explicit offline checks. Adblockers and privacy extensions cancel requests whose URLs match blocklists. Mixed-content rules refuse HTTP calls from HTTPS pages. None of these execute a line of your component code, which is why component debugging is always the wrong start.

Build the reflex: status 0 means open the Network tab, not the component file. The tab shows which of the five happened in seconds, while code review can burn hours proving correct code correct. Log zeros with their URL and network context so on-call inherits the classification instead of repeating the discovery.

import { Injectable } from '@angular/core';
import {
  HttpClient,
  HttpErrorResponse,
} from '@angular/common/http';
import { Observable, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';

export interface Profile {
  id: string;
  name: string;
}

@Injectable({ providedIn: 'root' })
export class ProfileService {
  constructor(private http: HttpClient) {}

  load(id: string): Observable<Profile> {
    return this.http
      .get<Profile>(`/api/profiles/${id}`)
      .pipe(catchError((err) => this.describe(err)));
  }

  private describe(err: unknown): Observable<never> {
    if (err instanceof HttpErrorResponse && err.status === 0) {
      console.error('Network failure, no response:', err.url);
    }
    return throwError(() => err);
  }
}

Reading the Network Tab Like a Flight Recorder

The Network tab is the fastest diagnostic instrument for status 0 because it records what the browser actually did. Reproduce with the tab open and read the rows. No row for your call means client-side blocking: offline, extension, or mixed content stopped it before dispatch. A red OPTIONS row with an access-control error means preflight rejection. A red GET or POST means the connection itself failed against a down or unreachable server. Three shapes, three owners, zero ambiguity.

Confirm outside the browser to split the suspects. curl -i against the endpoint bypasses extensions, CORS enforcement, and mixed-content rules: success through curl with failure in the browser proves a browser-side cause. A clean browser profile bypasses extensions while keeping browser rules: success there fingers an add-on. Each confirmation takes a minute and eliminates a whole category, which is why senior engineers run them before forming theories.

Record the evidence where the next person looks. Screenshots of the red row plus the console message turn vague user reports into actionable tickets. Better, teach support the three-shape vocabulary so incoming reports arrive pre-classified. Teams that read the tab first resolve most zeros in one pass; teams that start in code resolve them in one week.

import { Injectable } from '@angular/core';
import {
  HttpEvent,
  HttpHandler,
  HttpInterceptor,
  HttpRequest,
  HttpErrorResponse,
} from '@angular/common/http';
import { Observable, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';

@Injectable()
export class ZeroClassifier implements HttpInterceptor {
  intercept(
    req: HttpRequest<unknown>,
    next: HttpHandler,
  ): Observable<HttpEvent<unknown>> {
    return next.handle(req).pipe(
      catchError((err: unknown) => {
        if (err instanceof HttpErrorResponse && err.status === 0) {
          const offline = !navigator.onLine;
          console.error(
            `[net] ${req.method} ${req.url} offline=${offline}`,
          );
        }
        return throwError(() => err);
      }),
    );
  }
}

CORS Preflight Failures You Can't Fix in Angular

Cross-origin requests with custom headers, credentials, or non-simple content types trigger a preflight: the browser first sends OPTIONS asking permission, and only proceeds on a satisfactory answer. When the server's answer lacks the right Access-Control-Allow-Origin, methods, or headers, the browser cancels the real request and Angular reports status 0. The server logs show the OPTIONS arriving but never the POST, which confuses backend owners who see traffic and declare innocence.

No Angular setting fixes this, and the workarounds actively harm. Mode flags that suppress CORS also suppress reading the response, and interceptors that add more headers only trigger more preflights. The fix lives server-side: configure allowed origins explicitly, echo required headers, and handle OPTIONS without authentication. During local development, proxy the API through the dev server so the browser sees same-origin requests and skips preflights entirely.

Prevent recurrence with contract tests. A CI check that sends OPTIONS to staging and asserts the CORS headers for your production origin fails the pipeline the moment someone tightens server config. Document the required headers beside the endpoint definition so backend changes review against them. CORS is a server-client contract; test it like one instead of discovering breakage from user reports.

import { Injectable } from '@angular/core';
import {
  HttpClient,
  HttpHeaders,
} from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class OrderService {
  constructor(private http: HttpClient) {}

  // Custom headers trigger a preflight OPTIONS request.
  // The SERVER must answer it with CORS headers;
  // no client option can grant cross-origin permission.
  create(total: number): Observable<unknown> {
    const headers = new HttpHeaders({
      'X-Client-Version': 'web-2.4',
    });
    return this.http.post('/api/orders', { total }, { headers });
  }
}

Downtime, Offline, and Retry That Respects Idempotency

Transient zeros are normal weather: cold containers, sleeping serverless functions, deploy restarts, and tunnel Wi-Fi all produce brief windows with no response. Idempotent reads should ride through them with capped exponential backoff: retry three times at growing delays, then surface a clear error. Users never notice a 300-millisecond recovery, but they absolutely notice a spinner that dies on the first blip.

Mutations demand restraint. A POST that creates an order may have succeeded server-side even though the response never arrived; blindly retrying creates duplicate charges. Show explicit retry UI for mutations so the human decides, and design backends with idempotency keys where duplicates hurt. The rule is mechanical: safe to retry what reading twice won't break, human-gated for everything else.

Offline deserves first-class UI, not an error toast. Combine navigator.onLine with a lightweight heartbeat against your own API, and switch the shell to an offline state with queued actions where feasible. Users forgive honest offline screens; they churn on spinners that lie. Model network state as data, loading, failed-retryable, offline, and every zero lands somewhere designed instead of somewhere broken.

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable, timer, throwError } from 'rxjs';
import { mergeMap, retry } from 'rxjs/operators';

@Injectable({ providedIn: 'root' })
export class CatalogService {
  constructor(private http: HttpClient) {}

  // Safe retry: idempotent GET with capped exponential backoff.
  list(): Observable<unknown> {
    return this.http.get('/api/catalog').pipe(
      retry({
        count: 3,
        delay: (attempt) => timer(300 * 2 ** attempt),
      }),
    );
  }

  // Never auto-retry resource-creating POSTs: the first
  // attempt may have succeeded despite the missing response.
  create(payload: object): Observable<unknown> {
    return this.http.post('/api/catalog', payload);
  }
}

Adblockers and Mixed Content: the Silent Pair

Adblockers cause the most gaslighting zeros in production. A user reports checkout failing while your dashboards glow green, and reproduction on team machines never works because nobody on the team runs the blocklist that pattern-matches your /ads/campaign or /track/event endpoint. The request dies inside the extension, the backend logs nothing, and the console shows a plain status 0 with no hint of the true killer.

Diagnosis is environmental, not logical. Reproduce in a clean profile with extensions disabled: if the zero clears, walk extensions back on one by one until it returns. Audit endpoint paths for blocklist magnets like ads, track, analytics, and beacon, even when those endpoints serve core features. Renaming /track/purchase to /events/purchase has fixed more production incidents than any code change in this category.

Mixed content is the enterprise twin: HTTPS pages calling HTTP APIs get blocked before dispatch, failing only in environments served over HTTPS. Staging over HTTP masks it completely, which is why the checklist matters more than the fix. Enforce HTTPS-everywhere in configs, fail CI on http:// API URLs in production environment files, and diff serving protocols between environments on every infra change. Both ambushes share one lesson: user-specific zeros are environmental, so reproduce the environment before reviewing the code.

A Triage Loop for Every Status 0

A triage loop keeps status-0 incidents short. First, reproduce with the Network tab open and name the shape: missing row, red preflight, or failed request. Second, confirm outside the suspect layer with curl and clean profiles. Third, route to the owner the evidence names: backend CORS config, service availability, endpoint naming, or environment protocols. Fourth, verify the fix in the failing environment, not a convenient one.

Fifth, convert the incident into prevention. CORS contracts get CI checks, production configs get protocol linting, endpoint names get blocklist review, and idempotent reads get backoff retry. Each prevention item is cheap; each repeat incident is expensive and erodes trust in the integration.

Finally, write the postmortem around the evidence trail, not the code diff. Status-0 incidents rarely change application logic, so the valuable record is the diagnostic path: what the tab showed, what curl proved, and which environment detail differed. Future on-call engineers inherit a map instead of a mystery. The teams that triage this way stop fearing Unknown Error, because unknown just means unexamined, and they know exactly where to look. Keep the loop posted in the runbook so every on-call engineer follows it.