Status Page and Incident Banner Image Fallbacks

The irony problem

Status page images break during the incidents they describe

The most common cause of broken status page images is that the status page and the application share the same image CDN. During an S3 outage, a CloudFront degradation, or a Cloudinary incident, your application goes down and so does the image CDN that serves your status page logo and incident banners.

This is a design smell, not bad luck. A status page should be deployed on infrastructure completely separate from the application it monitors. Images are part of that infrastructure dependency—they should be sourced from a service with independent uptime.

Fallback.pics runs on Cloudflare Workers and edges, not on the same origin as your application. Referencing fallback.pics URLs for status page images means your visual assets have a separate availability dependency from your application assets.

Status page images

What images appear on status pages and need fallbacks

The main images on a status page are: the company logo in the header, service component icons (database icon, API icon, CDN icon), incident banner images (if used for severity), and the favicon.

Logo and service icons are the most critical. If those break during an incident, the page looks unbranded and untrustworthy at precisely the wrong moment. Incident banners are lower priority but should still have fallbacks.

<!-- Status page header logo with fallback -->
<img
  src="/static/logo.svg"
  width="160"
  height="40"
  alt="Acme Status"
  onerror="this.onerror=null;this.src='https://fallback.pics/api/v1/160x40/7C3AED/FFFFFF?text=Acme+Status'"
/>

<!-- Service component icon -->
<img
  src="/static/icons/api.svg"
  width="32"
  height="32"
  alt="API service icon"
  onerror="this.onerror=null;this.src='https://fallback.pics/api/v1/square/32/3B82F6/FFFFFF?text=API'"
/>

<!-- Database component icon -->
<img
  src="/static/icons/database.svg"
  width="32"
  height="32"
  alt="Database service icon"
  onerror="this.onerror=null;this.src='https://fallback.pics/api/v1/square/32/10B981/FFFFFF?text=DB'"
/>

Incident severity

Color-coded incident banner placeholders by severity

Some status page designs include a banner at the top of the page that changes color based on incident severity: yellow for degraded performance, orange for partial outage, red for major outage. If this banner includes a background image or illustration, that image needs a fallback.

Use severity-matched placeholder colors so the fallback state communicates the same visual urgency as the designed state.

const SEVERITY_COLORS: Record<string, string> = {
  none:      '10B981', // green
  degraded:  'EAB308', // yellow
  partial:   'F97316', // orange
  major:     'EF4444', // red
  maintenance: '3B82F6', // blue
};

function incidentBannerFallback(severity: string): string {
  const color = SEVERITY_COLORS[severity] ?? SEVERITY_COLORS.degraded;
  const label = severity.charAt(0).toUpperCase() + severity.slice(1);
  return `https://fallback.pics/api/v1/1200x80/${color}/FFFFFF?text=${encodeURIComponent(label + ' Incident')}`;
}

Statuspage.io / Atlassian

Custom domains and images on Statuspage.io

Statuspage.io (Atlassian) lets you set a custom logo and a custom domain for your hosted status page. If you set the logo to a URL hosted on your application CDN, and that CDN goes down in an incident, your logo breaks on your status page.

Set the logo on Statuspage.io to an image URL hosted on a completely separate domain. Fallback.pics URLs work for this: the URL is permanent, the CDN is Cloudflare, and the service has no dependency on your application infrastructure.

Freshstatus / Instatus

Self-hosted and third-party status pages: the same principle

Whether you use Freshstatus, Instatus, Cachet, or a hand-rolled status page, the infrastructure independence principle applies. Any image referenced in your status page template should be hosted on a domain with independent availability from your application.

For self-hosted status pages, audit your image references and replace any that point to your application CDN or origin with fallback.pics URLs or assets hosted on a separate static file host.

No-JavaScript environments

Status pages must work without JavaScript

During a major incident, some users will be on degraded connections or will have disabled JavaScript to reduce load. Status pages should render all critical information in pure HTML without requiring JavaScript. This means onerror handlers must work in plain HTML, not just in React or framework-managed components.

Test your status page with JavaScript disabled. Every img element should either load successfully or fall back gracefully via the onerror attribute—no framework required.

<!-- Plain HTML status page logo - no JS framework needed -->
<img
  src="https://cdn.acme.com/logo.svg"
  width="160"
  height="40"
  alt="Acme Status"
  onerror="this.onerror=null;this.src='https://fallback.pics/api/v1/160x40/7C3AED/FFFFFF?text=Acme+Status'"
/>

Internal links

Related reliability and fallback patterns

For changelog header image patterns and documentation page fallbacks that share similar reliability requirements, see the related posts.

https://fallback.pics/docs/
https://fallback.pics/placeholder-image-api/
https://fallback.pics/blog/changelog-header-image-from-text/
https://fallback.pics/blog/documentation-hero-image-fallbacks/