Today we've added a brand new server to our cluster and like our other servers this one is also named after a greek titan, specifically the goddess of dawn who rose each and every morning. Today our new server Eos will be rising to fill a great need within our cluster for more compute resources.

And the reason for that is over the past week we've received an unprecedented increase in very large customers which has put an increased load on the cluster. The performance has remained stable and fast but we always want to have a large buffer of extra capacity so in the event one or more server nodes has an issue the service is never disrupted.

And so Eos provides us with that extra buffer space. In-fact it's now our second fastest server in the cluster and later this year we will be transitioning some of our weaker nodes to stronger ones. Our intention is to double CPU performance and memory capacity on three of the five nodes before the end of this year.

A side benefit to adding Eos to the cluster is that our per-second API request limits have raised automatically by 25% so instead of being able to make 500 queries to the cluster per second you can now make 625. This should help those of you who see very high burst activity during attacks on your services and infrastructure.

We hope everyone had a great January just like we did and thank you for reading!

Today we've increased the price of two of our starter plans and we would like to show you the changes and explain why we've made them. But before we do that please note these pricing changes only apply to newly started plans which means if you're already subscribed to either of the plans we've increased prices on you will remain on the previous plan pricing.

In the above image you can see we've increased the price of our first starter plan by $1 and our second starter plan by 50 cents. The reason we've increased these plan prices is because while these starter plans are by far the most popular plans we offer they do not generate a lot of revenue for the business.

We have to acquire 50 customers at $1.99 each to bring in the same revenue as a single customer at $99.99 but those 50 customers take up a lot more of our human resources due to the high support needs they generate. So to help offset these support costs we have decided to increase these plan prices.

Another solution we considered was reducing the starter plan size from 10,000 to 5,000 daily queries but we found most of the users purchasing the $1.99 plan still fell under 5,000 daily queries and so it wouldn't solve the problem of our high support costs vs revenue generated by those users. In short, they would be unlikely to upgrade their plan to access more queries.

Price increases are not something we ever want to do as it heightens the barrier to use our service but in this case our business needs dictated this change be made. And of course these new prices only apply when you begin a new plan, users already subscribed will not be subject to the increased pricing while their plan remains active.

Thank you for reading and we hope everyone is having a great start to the new year.

We thought the previous post would be our last update for the year but there is one more thing. Today we've added support for continent data throughout our service. Which means when you now do &asn=1 you'll now receive a response like this:

{
    "status": "ok",
    "98.75.2.4": {
        "asn": "AS6389",
        "provider": "AT&T Corp.",
        "continent": "North America",
        "country": "United States",
        "latitude": "37.751",
        "longitude": "-97.822",
        "isocode": "US",
        "proxy": "no"
    }
}

The new field obviously being the one labelled continent. We've also added support for this within our custom rules feature as a new condition and output variable. This will allow easier rules that target all the countries within a continent without needing to break out the atlas and enter each country name manually.

This was a requested feature by several customers and we were more than happy to oblige :)

As the year comes to a close we thought it would be interesting to share with you the story of Raven which is our internal codename for our current inference engine. Currently Raven is at v1.32 and runs all day on every one of our servers and it consists of three parts.

1. The training engine which generally takes just under a month to create a new model which is then loaded on all our servers.
2. The real-time Raven client which runs on your queries live within only a few milliseconds.
3. The post-processing Raven client which runs on STYX our server dedicated to inference.

This is what Raven looks like when we're training a new model. Fair warning, it's not very visually interesting.

You can see in the above screenshot we started this model in early December and it is yet to complete. We're expecting it to finish around Christmas time. When developing the engine we had to overcome quite a few obstacles. Some of those we overcame by throwing more physical resources at the problem (cores, memory, storage). Others we had to solve with better software.

The first iteration of the Raven client was single threaded and we focused on acquiring servers with very high single thread performance (high IPC and clock speeds). We knew the industry wasn't moving in this direction and instead was building processors with higher core counts instead of increasing instructions per clock.

So after a lot of redevelopment the Raven clients that run on each of our cluster nodes were re-engineered to use multiple threads. We even added support for NUMA (non-uniform memory access) allowing us to efficiency make use of multiple processors in a single system. Our PROMETHEUS node for example is a dual-socket XEON system and it's where we primarily train the Raven engine once a month, it also runs the raven real-time client since this server also acts as one of our main cluster nodes which answers customer queries.

Another issue we've had to overcome is the engines determination throughput. Almost every day we deal with more queries than the day previous as the proxycheck service becomes ever more popular. In-fact it's not uncommon to break our single highest query day records several days in a row. So with all this constantly growing traffic the engine, especially the post-processing engine which is specifically designed to be more thorough needs constant adjustments and refinements to be able to process every address we receive on the same hardware we've allocated to it.

Some of these changes we've shared with you previously such as our bucket system of pre-computing and reusing data about similar addresses so that the engine doesn't have to start from nothing when forming a decision about an address it hasn't seen before.

Other changes to the way the engine thinks and weighs decisions have been made over time as we've learned what matters most when determining if an IP is bad or not. We have been relying a lot more on attack history as a way for the engine to make faster decisions as data that can be read from a database is a lot quicker to use than forming a decision based on weighting lots of abstract data points especially when a single address could have more than a thousand neighbours with varying levels of weighable behaviour.

We've also made a lot of structural changes to the plugins we've developed that our engine uses for evidence gathering. Making them more efficient with process recycling, shared memory pooling for their gathered data, socket reuse and remote socket use through an internal mesh network between our clustered servers and other resource use optimisations. We have in-fact developed an application we call Commander which can dynamically spin up extra resources as the load on our cluster becomes higher allowing us to expend more resources for evidence gathering when necessary.

To speak a little bit more about our evidence gathering, we do often probe addresses that the engine wants more information about. That means we will look for open services running from those addresses including proxy servers, mail servers and web servers. We will allow it to run scans to determine if an address has vulnerable services exposed to the internet. These scans help to provide concrete evidence of bad addresses and you'll find a lot of this data funnelled into our Compromised Server type responses. Other plugins for the engine load the website pages you include in your tags to us so we can categorise the page and assign it an access risk level.

With our constant adjusting of our behind the scenes software stack like Raven and its associated plugins (the Commander spoken about above is less than a year old for instance) it's not always evident that we're working on things, more visible features like the custom rules feature get a lot more show time on the site and our blog here but rest assured we're always improving things behind the scenes.

Over the past several months the service has been at its most stable with the least amount of node drop outs, least connectivity problems and our fastest ever response times. We've also been able to maintain a real-time processing ratio for our post-processing inference engine through constant code improvements without adding more hardware while still increasing the accuracy and thoroughness of the engine.

Looking past Raven we also greatly improved cluster communication. Many of you have noticed that the stats within your dashboard and at our dashboard API endpoints are updating significantly faster (at or under 60 seconds most of the time). This is not a coincidence, significant engineering effort went into redesigning that whole system for your benefit so we could make sure our stats continue to synchronise quickly no matter how much traffic you generate.

We are really looking forward to 2020 where we'll be continuing our refinement of our service in every which way. Thank you for reading this look at Raven and merry christmas!

Today we've released an update to our API Documentation page which fully explains how to use the new condition groups feature we introduced recently to the customer dashboard with new screenshots and instructions.

We also took this oppertunity to rename some of the option dropdowns within the Custom Rules feature so it's more intuitive. Gone are Condition Targets, Types and Values and in their place we now have API Provided Values, Comparison Types and Your Values.

That's all for today, we hope everyone is having a great week!

Today we sent out the second newsletter of this year to users who have the "New features and improvements" email toggle enabled within their dashboard. This has again been the widest distributed newsletter so far as the service continues to enjoy rapid growth.

If you didn't receive the newsletter but would like to read it you can do so here on our website.

We've made quite a lot of changes since April 2019 when we sent our last newsletter. We only publish two per year so you can expect our next one around April-May next year.

Thanks for reading and have a great week!

This is just a quick update for you. On November 7th we will be supporting Google Pay on our checkout system where you can setup a monthly or yearly subscription. This works exactly the same as when using a bank card or Apple Pay except you'll now see a Google Pay button if you've setup a Google Pay account. This is how it looks:

Very similar to our Apple Pay button. Over time we are adding more and more payment options such as Microsoft Pay, iDEAL and Sepa so stay tuned for more updates!

Today we're introducing our second major post-launch update to the custom rules feature found within your customer dashboard and it's quite a substantial update, but before we get to that we would just like to tell you about the customer response to the custom rules feature.

Since we released the custom rules feature on July 17th we have received an enormous amount of feedback from customers. Infact it has become the most discussed feature within the conversations we hold with customers. This is why soon after launch we added more conditions and early in August in our first major update to the feature we added output variables.

Todays update focuses again on rule conditions. Previously every condition you added to a rule all had to be true for that rule to be acted upon. This meant you may have had to create more rules than you wanted simply due to your need to account for every possible situation.

Sometimes you just want to create a rule that only applies to a few different IP Addresses, Countries or Cities and you don't want to create individual rules for each scenario. While from the start we supported the supply of multiple values for a single condition (and this is still supported) it was not a great experience to fill such a small box with so much data and it also limited you to one specific condition type for all the values you supplied.

With this new addition of condition groups you can create as the name suggests a group of conditions where only a single condition within that group needs to be true for the entire group to be satisfied. This allows you to easily create rules which apply to a whole bunch of countries or addresses or any of our condition types allowing very powerful rule targeting.

Below is a screenshot where we're creating a rule that only applies to a specific internet service provider in the United Kingdom. But we only want that rule to apply to three cities that they operate in and not the entire country. As you can see we've cleverly colour coded different conditions, pink conditions are required to be true while conditions wrapped inside a blue background only need a single condition within its group to be true.

Now this rule will only be activated if the ISP and Country matches the entries in pink and also when any one of the three Cities in the condition group are seen. And as you can see on the left within the condition group there is a dropdown. You don't need all the conditions within the group to be the same type. We could substitute one of the Cities for something else like an ASN number or an address range.

Like previously there are no limits on the amount of conditions you can specify for each rule and this extends to condition groups. You could if you wanted create your own whitelist or blacklist inside the rule feature using a single rule simply by creating a condition group and filling it with the Addresses, ASN's or IP Ranges you wish to whitelist or blacklist.

This update extends the foundation that the custom rules feature is built on. No functionality has been lost, you don't need to re-save your rules and the import/export features still work as you would expect. You can even import rules created with the previous version of the custom rules feature without issue.

This feature update has taken a lot of work but we know it's worth it. Customer response to Custom Rules as noted above has been phenomenal and it's our intention to keep adding new functionality over time with backwards compatible updates like this one so you can retain complete control of how our API interacts with your properties.

Thanks for reading and we hope everyone is having a great week.

Probably the feature that our customers interact with the most is our customer dashboard. Which is why we spend a lot of development time making it better. Over the past month we've added a lot of small enhancements which we would like to tell you about.

• Icons and Buttons around the Dashboard were updated, we also added icons to buttons that previously didn't have any.
• Greatly improved the speed at which your query statistics and positive detection log now appear (Avg 1 Minute).
• Made the Queries Today and Queries Total show the most accurate and up to date volume of queries you've performed.
• Added back support for customers to update their card details for a currently active subscription.
• Improved the appearance of the account information table at the very top of your dashboard and moved the copy API Key button.
• Added more text labels to paragraph blocks so it's easier to quickly read and summarise what a section is for.
• Added support for custom rule plans so we can offer our largest customers custom rule plans separate to query plans.
• Added a new custom rule output modifier to the rules feature which allows you to remove an output from the API by name.

These sorts of changes are always available to be read by hovering your mouse over the "Last Update" feature which is present at the bottom right of all our web pages.

Keeping you informed about the development progress of proxycheck.io is very important to us and while we usually wouldn't make a blog post for each of these changes on their own taken together there's a lot of improvements that warranted this blog post.

One thing we wanted to talk a little more about is the re-adding of support for customers to update their card information for a currently active subscription. When the European SCA (Secure Card Authentication) regulations came in we updated our integration to be compliant and during that time there was no way for us to do what's known as capture a customers card information for later use.

Due to that we had to remove the card updating feature from our website until our payment processor (Stripe) was able to provide such an integration which we could use, they were able to do that just ahead of the September 14th SCA deadline and we moved quickly to add that feature back within a few hours of Stripe launching it.

We're aware that some of you were inconvenienced when this feature was removed which is why we made every effort to add it back as soon as we could. As of now we're fully SCA compliant and as a result of that compliancy we now also accept Apple Pay which we spoke about in a previous blog post.

That's all for now, thanks for reading and have a great weekend.

When we added the new tag statistics section to the customer dashboard a week ago we instantly received requests from customers for an export API containing this data. We agreed with you that this feature was important and so today we've added it.

If you just want to see the documentation for this new API you can read that right here within our API documentation page.

This API is a bit different from the others, it has some more advanced features like being able to specify start and end unix timestamps to create a viewable time frame. This allows you to really look at tag use between any time period you specify. But we've also kept some more basic time controls like an easy to use days flag for our users who prefer that.

Below is an example of this new API endpoint showing how it can give you some great insight into your tag usage and the IP's triggering those tags.

{
    "www.example.com\/board\/ucp.php?mode=login": {
        "types": {
            "total": 10845,
            "rule": 468,
            "proxy": 10377
        },
        "addresses": {
            "178.137.81.87": 4263,
            "46.119.114.95": 3615,
            "46.119.115.202": 2967
        }
    }
}

With this new API Endpoint we've also updated our own dashboard implementation to use the same API and that brings with it enhanced performance, especially for users with a lot of tagged queries and we've also added the ability to click on entries to view the associated IP Addresses and a button to copy the addresses to your clipboard.

Thanks for reading and have a great weekend!