Is Fastly down?

Last checked 2m ago
Current status
Fastly is up

No incidents right now.

  • Official status page: fastlystatus.com
  • Checked every 5 minutes
  • 257 components tracked

Fastly is operational right now. Last checked 2m ago; the most recent incident resolved 2d ago.

Real-time Fastly status, recent outages, and incident history: pulled directly from Fastly's official status page at fastlystatus.com every 5 minutes. Pingoru tracks 257 Fastly services and has captured 91 incidents in the last 90 days (96.67% uptime). Get email, Slack, Discord, or webhook alerts the moment Fastly reports a new incident, free for 3 monitors, no credit card.

Users who monitor Fastly also follow these CDN services: Cloudflare imgix Font Awesome Twingate cdnjs WeTransfer Teleport Iristel Jitterbit Hygraph View all 8,000+ providers
Fastly uptime 96.67% uptime · past 90 days
Mon Wed Fri
AugSepOct
Less More

Active incidents 3

  1. Ongoing ● 8d 14h
    Started Oct 23, 2026, 02:20 AM UTC
    API & Configuration ManagementAPI ServicesFastly Control PanelFastly Control PanelFastly Control PanelFastlyFastly Control PanelAPI & Configuration ManagementAPI ServicesFastly
    Timeline · 1 update
    • investigating · Oct 23, 2026, 02:20 AM UTC

      Recently Fastly identified an issue affecting Domainr and Domain Research API. This issue may result in non-authoritative or "unknown" domain statuses for certain top-level domains (TLDs) for our customers. What happened? Domainr verifies domain status by connecting directly to registries. Following a routine certificate rotation, the new certificate no longer includes the client authentication component that some registries require to accept these connections. This reflects a public certificate authority (CA) change that took place earlier this year. For the affected TLDs, Domainr can't verify status directly with the registry. It falls back to resellers, DNS, or WHOIS where available. In situations where none are available, the API returns an "unknown" or “non-authoritative” status. The API continues to operate normally and returns successful (200) responses. Domain status data for affected TLDs may be less accurate or incomplete. What’s next? What do I have to do? There is no workaround, and no action is required on your part. Our Engineering team has already reached out to affected registries to partner with them on supporting and installing compatible certificates. Resolution depends on both this partnership and the completion of necessary system updates by the affected registries. Fastly Support is available to answer questions you may have and provide updates if available. We sincerely apologize for not providing earlier notice. We will update this status page as we receive more information. Customers with any other questions or concerns may engage with our Support team through https://support.fastly.com or by contacting your designated account management team members.

    Latest: Recently Fastly identified an issue affecting Domainr and Domain Research API. This issue may result in non-authoritative or "unknown" domain statuses for certain top-level domains…

  2. Ongoing ● 9d 21h
    Started Oct 21, 2026, 07:26 PM UTC
    FastlyFastlyCustomer ServicesFastlyCustomer ServicesCustomer ServicesGeneral UpdatesFastlyGeneral UpdatesFastly
    Timeline · 1 update
    • investigating · Oct 21, 2026, 07:26 PM UTC

      A security disclosure regarding php2shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) was published on October 21, 2026. In addition to implementing certain mitigations, we published a blog post about this disclosure for all customers. The post explains how we responded and shares steps you can take to protect your services. Additionally, we have published a second deep dive blog post to help you navigate and implement your own fixes. What happened? A set of critical vulnerabilities affecting all maintained PHP versions (php2shell) was disclosed, involving how the PHP engine handles fatal errors like memory exhaustion, timeouts, and dropped connections. To help protect customer environments, Fastly’s Security Research team, in collaboration with OpenAI and community partners, has developed a Virtual Patch for CVE-2026-109618 and CVE-2026-109619. To learn more about this vulnerability and our proactive protections, please read the blog posts linked in the reference section below. What you can do We strongly advise taking the following recommended actions: Apply Virtual Patching: Fastly Next-Gen WAF customers are strongly encouraged to apply the Virtual Patch for CVE-2026-109618 and CVE-2026-109619 across all vulnerable Edge and on-prem services. Opting in ensures you automatically receive updates as the rule is refined. Audit Application Servers: Identify all application servers running mod_php or php-fpm and treat all PHP applications as potentially vulnerable. Patch PHP Upstream: Apply official upstream patches. Patches are available in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 . For PHP 7.4, 8.0, and 8.1, or older versions, verify available patches with your Linux/package distributor. Fastly is actively monitoring for exploitation and new variants. Please stay aware of any further updates as this situation develops. Customers with any questions, requiring emergency WAF onboarding, or needing support may engage with our Support team through [email protected] or by contacting your designated account management team members. Reference: Critical RCE Vulnerabilities Discovered in Core PHP: CVE-2026-109618 and CVE-2026-109619 Fastly’s Proactive Protection for PHP2Shell, Critical React RCE CVE-2026-109618 and CVE-2026-109619

    Latest: A security disclosure regarding php2shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) was published on October 21, 2026. In addition to implementing certain mitigations, …

  3. Ongoing ● 11d 15h
    Started Oct 20, 2026, 01:18 AM UTC
    PlatformEuropePlatformEuropePlatformPlatformPlatformPlatformPlatformPlatform
    Timeline · 1 update
    • investigating · Oct 20, 2026, 01:18 AM UTC

      Our previous status post about this migration said no action was required. That was incorrect for Compute services that use mxp-milan-it as a shield location. If you have a Compute service that shields at Milan (MXP), you need to update it by November 2, 2026. Fastly can’t make this change for you because the shield location is set in your service’s code or Compute Config Store. We’re sorry for the confusion. What’s changing? Fastly is decommissioning the Milan (MXP) POP. Beginning October 26, 2026, and concluding by November 2, 2026, Fastly will gradually redirect shield traffic for the mxp-milan-it shield location to our Milan (BGY) POP. During this migration period, Compute services that reference mxp-milan-it will be redirected to bgy-milan-it. After the migration period ends, mxp-milan-it will no longer be a valid shield location, and Compute services that still reference it will get an error when creating the shield. How your service behaves after that depends on how your code handles that error. What’s next? What do I have to do? Compute services If your Compute service uses mxp-milan-it as a shield location, update it to bgy-milan-it before November 2, 2026. We recommend making this change as soon as possible. Find every place your service sets mxp-milan-it as a shield location, including shield names in your code and any values your code loads from a config store. Replace mxp-milan-it with bgy-milan-it. If you changed your code, build and deploy a new version of your service. If the shield name comes from a config store, update the stored value. If you manage your service with Terraform or other automation, update the shield name there too, so a later deployment doesn’t restore mxp-milan-it. For details on Compute services, see our Shielding documentation. Varnish Configuration Language (VCL) services If your VCL service uses standard shielding configuration, no action is required. Fastly will redirect your shield traffic to Milan (BGY) automatically. If your custom VCL or VCL snippets reference mxp-milan-it or the MXP POP in your own logic, update those references to bgy-milan-it before November 2, 2026. You can also switch your shield location to “bgy-milan-it” yourself in the Fastly control panel. See our Shielding documentation. When you switch to bgy-milan-it, your origin servers may see a temporary increase in requests while the cache fills in Milan (BGY). If you have any questions, please contact our Support team through https://support.fastly.com or your account team.

    Latest: Our previous status post about this migration said no action was required. That was incorrect for Compute services that use mxp-milan-it as a shield location. If you have a Compute…

Recent outages & incidents

Past 90 days
  1. Resolved 4h 53m
    Started Oct 29, 2026, 04:01 AM UTC · Resolved Oct 29, 2026, 08:54 AM UTC
    MexicoQueretaro (QRO)PlatformPlatformMexicoQueretaro (QRO)MexicoQueretaro (QRO)
    Timeline · 2 updates
    • investigating · Oct 29, 2026, 04:01 AM UTC

      Traffic to our Queretaro (QRO) POP is being redirected to nearby POPs due to an upstream provider issue in the region. Customers should see no impact. We will update this post once QRO returns to service.

    • resolved · Oct 29, 2026, 08:54 AM UTC

      This event has been resolved.

    Latest: This event has been resolved.

  2. Resolved 40m
    Started Oct 29, 2026, 03:10 AM UTC · Resolved Oct 29, 2026, 03:50 AM UTC
    North AmericaNorth AmericaPlatformMcAllen (MFE)PlatformPlatformMcAllen (MFE)
    Timeline · 4 updates
    • investigating · Oct 29, 2026, 03:10 AM UTC

      We are investigating elevated errors to our McAllen (MFE) Point of Presence (POP). All other products and services are unaffected by this incident.

    • investigating · Oct 29, 2026, 03:16 AM UTC

      Our engineers believe they have identified contributing factor causing the issue impacting the McAllen (MFE) POP. We are now developing a fix, and will post a new update once it has been fully implemented and we see signs of recovery. All other products and services are unaffected by this incident.

    • monitoring · Oct 29, 2026, 03:34 AM UTC

      Engineering has confirmed the impact to McAllen (MFE) POP has been mitigated.

    • resolved · Oct 29, 2026, 03:50 AM UTC

      This event has been resolved.

    Latest: This event has been resolved.

  3. Resolved 1h 28m
    Started Oct 29, 2026, 02:04 AM UTC · Resolved Oct 29, 2026, 03:32 AM UTC
    MexicoQueretaro (QRO)PlatformPlatformPlatformMexicoQueretaro (QRO)MexicoQueretaro (QRO)
    Timeline · 4 updates
    • investigating · Oct 29, 2026, 02:04 AM UTC

      We are investigating elevated errors to our Queretaro (QRO) Point of Presence (POP). All other products and services are unaffected by this incident.

    • investigating · Oct 29, 2026, 02:16 AM UTC

      Our engineers believe they have identified contributing factor causing the issue impacting the Queretaro (QRO) POP. We are now developing a fix, and will post a new update once it has been fully implemented and we see signs of recovery. All other products and services are unaffected by this incident.

    • monitoring · Oct 29, 2026, 03:21 AM UTC

      Engineering has confirmed the impact to Queretaro (QRO) POP has been mitigated.

    • resolved · Oct 29, 2026, 03:32 AM UTC

      During this incident, customers may have experienced elevated errors and increased latency for requests served through our Queretaro (QRO) POP from 23:21 to 03:29 UTC. This incident is resolved. For more information about this retrospective status post, please reach out to Support through https://support.fastly.com.

    Latest: During this incident, customers may have experienced elevated errors and increased latency for requests served through our Queretaro (QRO) POP from 23:21 to 03:29 UTC. This inciden…

  4. Resolved 2h 6m
    Started Oct 28, 2026, 05:02 AM UTC · Resolved Oct 28, 2026, 07:08 AM UTC
    North AmericaNew York (TSS)North AmericaNew York (TSS)PlatformPlatformPlatform
    Timeline · 2 updates
    • investigating · Oct 28, 2026, 05:02 AM UTC

      Traffic in New York (TSS) has been temporarily rerouted. All other locations and services are unaffected.

    • resolved · Oct 28, 2026, 07:08 AM UTC

      This event has been resolved.

    Latest: This event has been resolved.

  5. Resolved 1h 37m
    Started Oct 27, 2026, 11:05 PM UTC · Resolved Oct 28, 2026, 12:42 AM UTC
    FanoutFastly ComputeConfig StoreKV StoreSecret StoreAI AcceleratorEdge Cloud ServicesWebsocketsNext-Gen WAF (NGWAF)Compute
    Timeline · 4 updates
    • investigating · Oct 28, 2026, 12:10 AM UTC

      We are investigating elevated errors to our Compute, Next-Gen WAF (NGWAF) Services

    • investigating · Oct 28, 2026, 12:34 AM UTC

      Our engineers believe they have identified contributing factor causing the issue impacting the Compute, Next-Gen WAF (NGWAF) Services. We are now developing a fix, and will post a new update once it has been fully implemented and we see signs of recovery. All other products and services are unaffected by this incident.

    • monitoring · Oct 28, 2026, 12:35 AM UTC

      Engineering has confirmed the impact to Compute, Next-Gen WAF (NGWAF) Services has been mitigated.

    • resolved · Oct 28, 2026, 12:42 AM UTC

      Engineering has confirmed that Compute, Next-Gen WAF (NGWAF) Services has been fully restored. Customers may have experienced intermittent 5xx errors from 23:05 UTC on October 27 to 00:23 UTC on October 28. Service has been fully restored. This incident is resolved. Affected customers may have experienced impact to varying degrees and to a shorter duration than as set forth above. Note: Our Customer Escalation Management team will update the start date and time of the initial "investigating" status post upon the resolution of this incident. This update is meant to provide our customers and their end users with a potential impact window. The date and time mentioned in the message above indicates when the status post was requested by our Acute Incident Response team. Status Post, Created Date/Time: 2026-10-28 00:15:23 UTC

    Latest: Engineering has confirmed that Compute, Next-Gen WAF (NGWAF) Services has been fully restored. Customers may have experienced intermittent 5xx errors from 23:05 UTC on October 27 t…

See the full Fastly outage history

50 more incidents in the last 90 days, plus the full multi-year archive of per-service events and update timelines.

Browse Fastly outage history →

Or sign up free to get alerts when Fastly breaks · 10 free monitors · No credit card

Incident record

Since April 2026 · Fastly Statuscast · 257 components checked every 5 minutes
181incidents recorded
181last 12 months
56last 90 days
2 daystypical duration, 12 months

The longest incident in the last year, Port Blair (IXZ) Rerouted Traffic on July 28, 2026, ran for 38 days. 59 maintenance windows announced in the same period.

Most affected components, last 12 months

  • Platform61
  • Platform52
  • Platform41
  • Platform40
  • Platform32

Latest incidents

  • Upcoming change to geolocation metro code values December 1, 2026 · still open · notice

    On December 1, 2026, at 09:00 UTC, our geolocation data vendor will be releasing an update. This update will result in US metro_code values changing.…

  • Queretaro (QRO) Rerouted Traffic October 29, 2026 · 5 hours · notice

    Traffic to our Queretaro (QRO) POP is being redirected to nearby POPs due to an upstream provider issue in the region. Customers should see no impact. We will…

  • Elevated Errors & Latency for McAllen (MFE) October 29, 2026 · 40 minutes · major outage

    We are investigating elevated errors to our McAllen (MFE) Point of Presence (POP). All other products and services are unaffected by this incident.

Outage history

Past 90 days · 56 incidents· showing the latest 55 View full outage history →