One of the most consistently requested things from developers integrating our service into their software has been an OpenAPI specification and today we're happy to say that wait is over. We've published an OpenAPI v3.1.0 specification covering both our v3 API and our Dashboard APIs, and it's available right now from our API documentation page.

Why Now?

With our v3 API preparing to leave open beta and become our new stable API, this felt like exactly the right moment to ship the spec. We wanted it in place before v3 goes stable so that developers building integrations from day one have a machine-readable description of the API to work with rather than hand-rolling clients purely from written documentation.

It has been one of the most frequently requested things we've heard from users over the years, and we're glad we were finally able to prioritise getting it done properly. Producing a spec for an API that's still in active development is a balancing act, but we felt the timing was right. The v3 API has now gone through several substantial beta releases and its structure has settled considerably.

What's Covered?

The specification covers both major surface areas of our API offering:

The v3 API
Our new-generation proxy, VPN and threat intelligence API. This includes IP and email address checking, the full response schema (network data, location, detections, risk scores, confidence scores, operator information, detection history, attack history and more), query flags, and all status and error response formats.

The Dashboard APIs
The full suite of programmatic dashboard controls, including positive detection exporting, tag exporting, account usage and query volume exporting, custom list manipulation (add, remove, set, clear, erase), custom rule management (print, enable, disable), and CORS origin list management.

All of this is described using the OpenAPI v3.1.0 format, which is the current specification version and brings full alignment with JSON Schema, meaning you can use the spec directly with any modern tooling that supports it.

What Can You Do With It?

Having a formal OpenAPI spec opens up a lot of practical possibilities for developers:

• Generate a client library in your language of choice using tools like openapi-generator or Speakeasy. If your language isn't yet represented in our code libraries, this is the fastest path to a typed, fully featured client.
• Explore the API interactively by importing the spec into Swagger UI, Scalar, or Stoplight — useful for understanding the response schemas before you write a single line of code.
• Import it into Postman or Insomnia and have a ready-made collection of every endpoint, with example request parameters and expected response shapes already filled in.
• Validate your integration by using the spec to confirm that your code is constructing requests correctly and handling all documented response fields.
• Stay up to date — as the v3 API evolves post-beta we'll be keeping the spec in sync with the documentation, so you'll always have an authoritative reference.

Where to Find It

The spec is documented and available for download from the OpenAPI Spec section of our API documentation found here.

A Note on the v3 API Beta

For those who haven't been following the v3 beta, our v3 API is a significant overhaul of how we present data. It moves to a fully nested JSON structure, returns booleans instead of yes/no strings, always includes a rich set of detection data without requiring individual query flags, introduces proper HTTP status codes for denied and failed requests, and adds new sections like detection_history and attack_history. It also brings a confidence score alongside the risk score, giving you finer-grained control over how aggressively you act on detections.

If you're currently on v2, there's no rush. We're committed to supporting the v2 API for at least until 2035. But if you're starting a new integration, v3 is where you want to be, and the OpenAPI spec is the best place to start.

As always, if you have any feedback — on the spec, the API, or anything else — please get in touch. We do read and reply to every message. Thanks for reading and have a wonderful week!

Ten years ago, proxycheck.io opened its doors with a single purpose: give developers and website operators a fast, reliable way to detect proxy and VPN traffic. A lot has changed since then, but our purpose hasn't.

We started as a simple API, just a single page service and completely free. Today, proxycheck.io is a globally distributed, multi-region detection platform fielding billions of queries every month for customers ranging from solo developers running hobby game servers to enterprise businesses protecting their platforms at scale. This birthday post is a chance to look back at how we got here, celebrate what we've built, and share our sincere thanks towards all our customers.

The world we launched into

When proxycheck.io launched, the proxy landscape looked very different. The overwhelming majority of proxied traffic ran through free, open proxy servers — poorly maintained machines with forwarded ports, scraped from lists updated every few hours. Detection was a relatively straightforward cat-and-mouse game: collect the IPs, publish a list, update it regularly.

Ten years on, that world is gone. The rise of residential proxy networks - services that route traffic through millions of ordinary consumer devices using mobile broadband and home broadband connections - has fundamentally changed what detection means. You can't just block a datacenter range anymore. You're contending with addresses that look, to every other system, exactly like a real home user in a real city. Keeping up with that shift is perhaps the defining technical challenge of our second decade.

A timeline of the last ten years

2016 - Service launches with the v1 API

2017 - Inference engine added and honeypots

2018 - v2 API ships; bulk IP checking is added with a new API format

2019 - Risk scores, attack history & custom rules introduced

2020 - CORS support & North American infrastructure goes live

2021 - VPN operator cards; dark mode dashboard; Asian infrastructure goes live

2022 - Postcodes added to the API; HA improvements; Unified Changelog;

2023 - Timezone & currency data added to the API

2024 - New status page; device estimates and hostnames added to the API; Account Activity Log;

2025 - v3 API beta begins; confidence scores are added;

2026 - 100 times improvement in residential proxy coverage; detection history added; 10th birthday

And alongside those major features we redesigned many things, the dashboard saw lots of love, the web interface, the lookup pages, our API documentation and the site in general with our light/dark glass themes and navigation bar.

Milestones we're proud of

2019: Custom Rules We gave customers the ability to write their own logic on top of our API. Whether whitelisting cloud gaming services, blocking specific VPN operators or entire nations this feature lets you do it all. This feature that started with just 3 rules allowed per account has grown to become one of the most popular features we offer, in-fact thouands of accounts have created or imported at-least one rule each. This was such a monumental feature for us as it was extremely complicated to implement and took a massive amount of engineering effort.

2020: First servers outside Europe For the first three years, every request routed through our European infrastructure. The launch of our North American cluster was a milestone: suddenly customers in the Americas saw dramatically lower latency, and we had real geographic redundancy for the first time. This was a big monetary commitment to invest in our potential growth and acquire more customers in North America, it did pay off and we've since expanded our infrastructure there twice aswell as adding servers in Asia.

2021: VPN Operator Cards Rather than just returning "VPN: yes", we began telling customers which VPN operator controlled an address, with rich metadata they could build real logic around. The operator intelligence in our new 2026 v3 API - including cross-operator detection and specific service classification - is a direct evolution of this original idea.

The thing we've never changed

Across every API version, every server upgrade, and every pricing revision, one thing has stayed constant: our free plan. One thousand queries per day, with full access to the exact same data and detection accuracy as every paid plan. No degraded results, no watermarked data, no bait-and-switch.

We've also kept something else consistent: our pricing philosophy. When we raise prices - as we did for the first time in six years this past January - existing subscribers kept their existing rate. Loyalty is rewarded here, not penalised. The price you initially subscribed at is the price you pay until that subscription is changed or cancelled.

Thank you, truly.

None of this exists without the people who trusted proxycheck.io early - the platform operators who integrated us into their first Minecraft servers, their early WordPress blogs, their website authentication systems. The developers who wrote libraries, plugins and applications that integrated our API. The customers who sent us bug reports and feature requests. You all made this service what it is and we won't ever forget that.

Ten years. Here's to the next ten, thanks for reading and have a wonderful week.

Over the past several months we've been focusing heavily on residential proxy services. The kind of service where you pay a subscription to proxy your traffic through mainly wired residential and wireless 4G/5G internet connected devices.

The reason we've placed such a focus on these services is because of their growing prevelance, the days of free and abused proxies being the predominent type of proxy on the internet is long gone and now paid services that offer access to millions of consumer devices have taken over.

But these do present a problem for a service like our own because unlike the free proxies these don't require port-forwarding and the paid services never provide a raw IP address for you to connect through directly. Instead the addresses are masked behind gateways that are controlled by the paid service and they forward your traffic to a randomly selected IP address within their fleet of devices.

Due to this it's not uncommon to be given an IP address which is shared by many customers of the same internet service provider via technologies like CG-NAT or the address stops acting as a proxy server very quickly when it belongs to an internet service providers dynamic address pool with short lease times.

So we've been trying to tackle this issue, the main way we've gone about it is by massively increasing the number of services we access to obtain the addresses of their entire fleet while simultaneously reducing the time we list each individual address for. This has had the benefit of reducing false positives while maintaining a decent detection rate of addresses that are still acting as proxy servers.

But it hasn't been as good as we would have liked. For every hour that we reduce the time we list an IP we're giving up literally thousands of working proxies that should still remain detected. So to tackle this problem with more nuance we've added a new rules-based system to our address collector which will increase or decrease the timeframe that we list an IP based on several factors including:

1. How many times we've used the IP successfully as a proxy server.
2. How long its been since we first used the IP successfully as a proxy server.
3. How recently we used the IP as a proxy server prior to the latest detection.
4. How many unique sources provided us the same IP address.
5. Specific weights for specific proxy operators as some use more dynamic addresses than others.
6. Specific weights for specific internet service providers as some use CG-NAT or have very dynamic address pools.
7. Specific weights for different line types (Residential, Wireless, Business, Hosting etc).

This new rule based system doesn't just apply to residential proxy services with known operators, it also applies to our VPN detection and all other kinds of positive determinations that we're performing. This system is highly variable and may increase the time we display an address by as little as 0.5% or by as much as 1,000%.

The point of the system is to allow us to still expire addresses that we've only seen once or rarely very quickly while making sure that the most abused addresses don't get delisted too early.

As we mentioned above while reducing the time we display an address helped prevent false positives there have been occasions where we've seen some addresses that have clearly been abused as proxy servers for a long time (more than a month continually) get delisted early merely because we weren't given them by a residential proxy service frequently enough for them to remain listed.

In one case we had listed and then delisted an address more than 30 times leaving many hour-long gaps in its detection due to the infrequency that we were given the address combined with how soon we were delisting it. With the new system this wouldn't happen and this address in our simulations would have remained listed for the entire time period that it was being abused.

This change is live right now for all our v1, v2 and v3 API versions as this is a backend change to the amount of time we store and display positive detections and not an API specific logic change. We launched this change today after extensive testing and our hope is it will allow us to further reduce default listing times once enough data has been built up for the rules to work effectively.

Thanks for reading and have a wonderful week!

We're excited to announce a major update to our ongoing v3 API beta, released today this version introduces some major new features and enhancements, as a result we've issued a new dated version which is selectable from within Customer Dashboards, or by supplying &ver=11-February-2026 with your requests to our v3 API endpoint.

What's New

Detection History Tracking

Our API now includes detection_history, providing you with a complete timeline of an IP addresses listing status. This feature shows:

• Whether the listing is currently live or has been delisted
• Precise timestamps in ISO 8601 format indicating when entries were or will be delisted

This historical context helps you understand the lifecycle of positive detections and we have a new query flag to view historical data.

The &history=1 flag

When you provide this flag we will show you the positive detections we've had for this address no matter how long ago they were. You can also combine this with the &days= flag to restrict the history between now and a point in the past you care about.

For example if you supply &history=1&days=7 we will show you the full positive detection history of an IP over the past 7 days even if we've delisted it from our live results. Without the &history=1 flag the &days=7 may be disregarded if we've already delisted an IP due to us not being confident about the determination anymore. We may lose confidence in a listing due to its age, this is because the listings become stale and thus inaccurate unless the data is refreshed, if we've not seen an IP acting maliciously in a while it's likely safe again and thus needs to be delisted.

In the past we allowed the &days= flag to act like a history flag, but due to misuse by customers we restricted how far back it can go to no further than our delist times for the data we hold, this &history=1 flag brings back the capability to look further back beyond our delist times whilst maintaining the metadata you need regarding the addresses delisting time so you know whether we've delisted the data before you make a final decision.

Attack History & Classification

The "new" attack_history feature delivers comprehensive intelligence about recent malicious activity. I put new in quotes because this is actually a feature from our v2 API that we've brought to the v3 API. It's simpler, more standardised and thus easier to parse programmatically. For each IP address, you'll receive:

• A list of the attack types the IP has been observed partaking in
• Numbered counts showing the frequency of each attack type

Gone from the v2 API is a numbered total, you can easily do this in your own programming language so it felt redundant to include in this version. This granular attack data should enable you to assess threat severity and be more granular about the addresses you allow to access your sites and services.

Enhanced Operator Intelligence

We've significantly improved the operator information section with two key enhancements:

Specific Service Classification

We now identify the exact services provided by IP address operators as an array, which means you may receive one or more of these services in the new services section of the operator data:

• Residential proxies
• Wireless proxies
• Datacenter proxies
• Residential VPNs
• Datacenter VPNs
• Web scraping
• And more

Cross-Operator Detection and Display

The new additional_operators key reveals other operators we've observed controlling the same IP address. This multi-operator insight helps you:

• Identify IP addresses with shared infrastructure
• Detect operator networks and relationships
• Understand when an address is experiencing broad abuse

We will always put the most common operator we see as the main/primary operator with the others as additional operators. The reason we've added this section at all is because our huge increase in residential proxy detection has revealed a lot of shared infrastructure amongst these organisations.

To put it simply, they're sharing the same pool of compromised computers and we want to show that in our data so you can more easily identify addresses you should always keep blocked, the most abused ones.

We've also updated our lookup pages to show additional operators in the top operator card section.

Some API output format changes

The biggest change regarding the API format is that the operator section will now always be present for every IP but if no operator is available you'll receive an operator: null result. This is the same for our new detection_history and attack_history sections, if data doesn't exist they'll say null too.

We've done this to keep the API response consistent and to make developers aware that there may be additional data presented even if the IP they're checking right now doesn't feature it.

Getting Started

This new dated version of the API is available right now as we mentioned at the top you can select it from within the Customer Dashboard or by supplying &ver=11-February-2026 with your requests to our v3 API endpoint. Thanks for reading and have a wonderful week!

Enhanced Proxy Detection and Strengthened Security

We're excited to share two significant updates that improve both the accuracy and security of our platform.

10x Increase in Residential Proxy Detection Coverage

We've dramatically increased our residential proxy address collection, specifically we're now collecting 10 times the volume of proxy addresses per day compared to what we were doing a week ago. This substantial increase will have a direct correlation on proxy detection rates and we're not done, we intend to further increase our detection rate of residential proxies in the coming weeks as we tune the infrastructure we've built to tackle this problem.

Improved Accuracy Through Reduced Display Time

With this increased data collection rate, we're now encountering the same residential proxy addresses multiple times within a 24-hour window. This repeated observation has enabled us to make an important optimization: we've reduced the average display time of results on our API from 48 hours to 24 hours for residential proxies.

This change delivers a meaningful reduction in false positive rates. Here's why: when we observe a proxy address multiple times in quick succession, we can confidently extend its active status. Conversely, addresses that appear only once or twice and then disappear are more likely to be outliers—IP addresses that have ceased operating as proxy servers. By tightening our display window to 24 hours, we can more effectively filter out these outliers while maintaining coverage of genuinely active proxy infrastructure.

The net result is fresher, more accurate data that better reflects the current state of residential proxy networks and a reduction in the support tickets made by your customers to request their addresses be allowed to access your services.

Comprehensive Security Infrastructure Audit & Upgrades

In our ongoing commitment to protecting our platform, we've performed an internal security audit and implemented a suite of security protocols:

DNS and Email Security Enhancements

DNSSEC (Domain Name System Security Extensions): We've deployed DNSSEC to protect against DNS spoofing attacks, ensuring that users connecting to our platform are actually reaching our legitimate servers, not malicious imposters.

CAA (Certification Authority Authorization): By implementing CAA records, we've explicitly specified which certificate authorities are authorized to issue certificates for our domain, reducing the risk of fraudulent certificate issuance.

MTA-STS (Mail Transfer Agent Strict Transport Security): This protocol enforces encrypted SMTP connections for email delivery, preventing man-in-the-middle attacks on our email communications.

Enhanced SPF (Sender Policy Framework) Records: We've refined our SPF configuration to better prevent email spoofing and improve our email deliverability and authenticity.

TLS-RPT (TLS Reporting): We've enabled TLS reporting to monitor the effectiveness of our email security measures and quickly identify any delivery issues or potential security incidents.

Automatic Email Replies: Not really security related but we noticed in our audit we do not automatically reply to a customer email to let you know we received your mail and to expect a reply from us. We now send these so you can be sure your mail reached us successfully.

What This Means for You

These security enhancements work together to create multiple layers of protection for our platform and your data. From preventing domain hijacking to securing email communications, these protocols represent industry best practices in modern web security.

Looking Forward

These updates reflect our dual commitment to delivering accurate, timely threat intelligence while maintaining the highest security standards. As residential proxy networks continue to evolve, we'll continue investing in both our detection capabilities and our infrastructure security.

If you have questions about these updates or how they impact your use of our platform, please don't hesitate to reach out to our support. Thanks for reading and have a wonderful week!

Today we've deployed a new server in Singapore to double the capacity and redundancy of our Asian infrastructure. We're doing this because last month we had an ill-timed fault with our only Asian server which we weren't able to resolve for about 10 days and so we wanted to expand our Asian infrastructure so that our customers don't face higher latency if the same thing were to occur again and also if we're performing scheduled maintenance.

You may have seen in the news recently that the price of memory and to a lesser extent storage has increased in price due to demand far exceeding worldwide supply. This has had an impact on our urgency to add an extra server before the pricing became completely unreasonable, already this server while being the same specification as our other Singaporean server will cost us twice as much every month and it had a significant up-front allocation fee when in the past no fee was imposed.

In addition, while Singapore is a great place to host servers as it has great network connectivity to surrounding countries and a stable government it has some of the highest square-meter land costs in the world and as a result datacenter space is sold at an extreme premium. We are looking to pay eight times higher prices for servers in Singapore when compared to India and three times higher costs compared to Europe. So us having multiple servers there is a significant monetary investment but one we know will benefit our growing customer base.

So that's the update for today, the new server called PLUTO is live and accepting requests right now. As always, thanks for reading and have a wonderful week.

As we mentioned in this blog post on November 1st we would be increasing our prices in January 2026, and as it's the first day of January we decided to do it today. We also wanted to note that we kept large disclaimers available for two months on both our pricing page and customer dashboard, explaining how to lock in the lower prices ahead of today. This way, everyone was well-informed about the upcoming price increase and could plan accordingly.

Every price of every plan we offer has increased however the percentage of the increase differs between plans with the largest proptional increase in price focusing on our Business and Enterprise plans. For our most popular Starter plans we've increased the prices by only $1 which is effectively a 33% to 20% increase depending on the Starter plan.

This means our previous lowest plan, which has been $2.99 since January 2020, is now $3.99. We think this still offers incredible value and we've not changed any plans quantity of daily queries, custom rules, custom lists or burst tokens. Same features, same service just at a new price.

For our Pro plans we've raised the first plans price from $6.99 to $9.99 and we like the idea of seperating each of our three Pro plans by $5 instead of the previous $3.

As mentioned, the largest increase comes to our Business and Enterprise plans. The first Business plan which used to be $19.99 is now $29.99 which represents a 50% increase. Similarly, the last Buisiness plan, which was $49.99 is now $99.99, which represents a 100% increase in price. We've done this because the cost to deliver this plan (2.56 Million daily queries) is substantial and we want to be able to purchase more powerful servers to better serve the high capacity needs of our largest customers.

As we move to the Enterprise plans, the first plan has also seen a 100% increase from $99.99 to $199.99 and that's because we're sticking to a linear cost-per-query structure beginning at the 1.28 Million daily queries mark (Business plan, $49.99 per month). So for every 1.28 million daily queries, it'll cost $49.99, which is why the 5.12 Million plan is now $199.99 (4 x $49.99 essentially plus a few cents) and our largest 10.24 Million plan is now $399.99, up from $199.99. We do want to point out that we're one of the few SaaS businesses in the industry that has transparent and available enterprise pricing right on the webpage. We don't do "call us for pricing" sales tactics that lead to upselling.

Now as always, when we increase our prices, they only apply to newly started or altered plans. So the subscription you already hold will not change in price, you will continue to pay your existing lower price until you cancel your plan. We've also updated the plan section area within the Dashboard to clearly show that you're subscribed to a plan at a lower price than currently offered so it's not confusing.

We know that nobody likes price increases, we've been able to keep our prices the same since 2020 but unfortuantely the higher costs of everything, including energy, infrastructure, advertising and more, have meant we needed to increase our prices. Thankfully, we have a lot of plans, which means we can offer pricing that fits exactly what you need to save you the most amount of money and we've been able to protect our lowest cost starter plans, keeping them very competitively priced, which maintains the accessibility of our service.

And of course, we still offer our full-featured free plan that has complete access to the exact same API results as our paid plans with 1,000 daily queries. We're fully committed to our free plan and we have no plans to stop offering it or degrade it in any way.

Thanks for reading, and have a wonderful new year.

Our Brand New Web Interface: Speed Meets Simplicity

We're thrilled to unveil a completely redesigned web interface for proxycheck.io, now available at https://proxycheck.io/web/. This isn't just a visual refresh it's a ground-up reimagining of how you perform bulk lookups, combining a modern user interface with class-leading performance and full v3 API compatibility.

A Fresh, Intuitive Design

The new interface features a clean, modern design that makes checking IP addresses more intuitive than ever. Here's what the main overview of results looks like:

This new pane interface shows more addresses in a denser way while maintaining access to important controls like copying. New with this interface is an expand feature which will pop out a pane into a larger modal.

Rich Contextual Information

We've added intelligent tooltips throughout the interface that provide detailed explanations without cluttering the main view. Hover over any element to reveal comprehensive information including the specific detection types, location and network data.

Since our new v3 API supports multiple detection types for a single address we felt it was important to include the colourful detection icons within this context tooltip so that you can identify at a glance all the various detections we've made about a single address.

Detailed Results Breakdown

Below the main overview though you'll find an expanded results section that provides granular details about each address you've checked:

These detailed breakdown panes will change size depending on how many varied results you're receiving to maximise the viewable area of the page. They are also color-coded for glancing and of course the colors and icons match those found within the contextual tooltips for visual coherencey.

Unprecedented Performance

Beyond the visual improvements, the new interface delivers exceptional performance that sets a new standard for bulk address checking and we've also increased the maximum amount of addresses you can check in a single request through the interface from 10,000 to 20,000.

• Check up to 20,000 addresses in a single request
• Check 1,000 addresses in just 200 milliseconds
• Check 10,000 addresses in under 1.7 seconds

Don't just take our word for it, below is a real-world performance example checking 10,000 varied addresses:

This blazing-fast performance means you can validate large lists of addresses in real-time, without the traditional waiting you may have experienced with our previous web interface that utilised our older v2 API.

Try It Now

The new web interface is live and ready to use at https://proxycheck.io/web/. We invite you to experience the speed and simplicity for yourself.

As always, we'd love to hear your feedback. Let us know what you think of the new design and how it's working for your use cases. Your input helps us continue improving the service. Thanks for reading and have a wonderful week!

New API Beta: Enhanced Detection Insights

We're excited to announce the release of our new API beta version, dated November 20th, 2025. This update brings new responses that give you deeper insights into detection results and help you make more informed decisions. This is our third dated version of the v3 API as the beta continues.

What's New in the Beta

Confidence Scores

The headline feature of this release is the addition of confidence scores for all detections. Every detection now includes a confidence value ranging from 0 to 100, indicating how certain the API is about its findings. This numerical score gives you immediate insight into the reliability of each detection, allowing you to:

• Filter results based on confidence thresholds
• Prioritize high-confidence detections for immediate action
• Flag low-confidence results for manual review
• Make more nuanced decisions based on detection certainty

The score is heavily weighted towards recent detections meaning as the time grows between now and our last detection the confidence score will reduce. This allows us to present results for a longer time period because the confidence score will help you decide how to action the result.

One thing to note about this release, because of the new confidence score some data that was previously expired quickly will linger for a much longer time. Due to this we're going to be hiding results on the API if you don't supply an &days= flag with your requests so that we can provide a safe default.

As an example, residential proxy results typically expire within 48-hours but you can keep them visible for much longer by supplying &days=14 which would keep them displayed for 14-days whilst the confidence score will degrade the further out from our latest detection.

Temporal Detection Data

We've also added two new fields to the detection section that provide important temporal context:

• first_seen: When the detection was initially identified
• last_seen: The most recent occurrence of the detection

These timestamps will help you understand the timeline of detections and track persistence.

Lookup Page Updates

We've also upgraded our lookup pages to take full advantage of the new API version. The interface now displays:

• Confidence scores for all detections
• First seen and last seen timestamps
• Enhanced appearance of detections making it easier to parse at a glance

This means you can explore detection data more thoroughly directly through the web interface, without needing to make API calls for basic queries.

Getting Started with the Beta

The new beta API version is now available for testing. We encourage you to explore these new features and share your feedback with us. Your input during this beta phase will help us refine the API before an eventual stable release that we think will come early next year.

You can begin using it by supplying &ver=20-November-2025 with your requests to the /v3/ endpoint, or you can select it from the v3 API dropdown selector within the customer dashboard. If you've set your API version to Latest Stable Version you'll already be using the new release.

We've also updated the API documentation page and test console.

Questions or Feedback?

If you have any questions about the new beta features or encounter any issues during testing, please don't hesitate to reach out to our support through the contact us page and as always, have a great weekend.

Today we experienced the longest contiguous downtime in our services 9 year history, lasting around 3 hours. The cause was a worldwide outage of the CloudFlare content delivery network of which we are a customer. They have an incident report you can read here.

EDIT:// CloudFlare have now also posted a blog post going into more detail which you can read here.

First of all we would like to apologise for this downtime, we truly believe we have done everything we can to mitigate downtime but eventually there is a single point of failure somewhere and for us that is CloudFlare. Whether we run our own DNS servers, nameservers or even own and operate our own IP addresses and autonomous networks eventually you have to rely on a 3rd-party somewhere that has the potential to go down.

The reason that we chose CloudFlare to be our sole single point of failure is because the vast majority of our own customers use CloudFlare. Based on the metrics we have around 80% to 95% of the websites that utilise our API are using CloudFlare. And so this means if there is a CloudFlare outage, it's likely our own customers are also experiencing the same outage of their own websites and so this reduces the impact of our downtime.

We're one of the millions of websites that went down today including OpenAI, Spotify, Uber, Twitter/X and even Downdetector.

There are ways in which we could utilise multiple content delivery networks, for example we could use Microsoft Azure CDN or Amazon AWS CloudFront alongside CloudFlare, both of which also experienced hours-long downtimes in recent weeks. But this approach of using multiple CDN's at once simply moves the single point of failure higher up the chain, at the load balancer level that chooses which CDN your traffic is handled by. If this were to have an outage instead of CloudFlare then our outage would not coincide with our customers who use CloudFlare and thus have a larger impact.

We made all of these considerations and researched our options the last time we had a major CloudFlare outage which lasted 38 minutes in 2019. We thought utilising multiple CDN's would be a simple solution and we did even trial some solutions but ultimately we saw that we were just trading one single point of failure for another and the impact on our customers would be larger if we didn't make just CloudFlare our single point of failure.

The reason we're writing this blog post with the above detailed explanation behind our reasoning is because we do want to explain not only why we were down but what lead to the decisions that resulted in us choosing CloudFlare in the first place and more specifically why we know they're our single point of failure and yet we maintain having them in that position within our infrastructure, the impact on our customers specifically is the lowest with CloudFlare of all the other options available.

We're sure that CloudFlare will make a blog post of their own going into specific detail about this outage and what they'll change in the future. We will update our own blog post here with a link to their explanation at that time. EDIT:// That blog post is now available here.

If you would like to get in touch with us for any reason please feel free to use the contact page. Thanks for reading and have a great week.