Probe Server Changes [NY] and Addition [MO]

The following probe servers will be changing IP addresses on 2018/05/09:

New York City, New York (NY) – USA is changing from
( / 2604:180:2:38f::928a)
( / 2605:9f80:c000:127::2)

We’re also adding a new probe to the North America region on 2018/05/09:
Kansas City, Missouri (MO) – USA
( / 2604:4300:a:9d:202:c9ff:fec0:da0e)

Please adjust your firewalls appropriately if you whitelist so your checks do not fail because of the probe IP address changes.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ, a text file, and via DNS query,


[UPDATE – 2018-05-09 19:00GMT-6] – IP changes and probe addition complete.

Update to TOS and Privacy Policy – NodePing and GDPR

Part of the benefit of being a relatively small distributed company in the Internet cloud age is that we can have a global reach without requiring a lot of infrastructure and overhead. We have customers all over the world, but we have almost no presence anywhere beyond our home office. Our people can work from anywhere with a good Internet connection. Since we work in the cloud, most of our computer systems are in places we have never been. We don’t even handle payment information directly in any of our workplaces. Payment information is passed directly to our payment processors. Working in the cloud age helps all of this work smoothly and safely with very little physical infrastructure required.

The downside of all of that is that our customers are all over the place, including legal jurisdictions all over the world. The regulatory world hasn’t really caught up with the idea of cloud based distributed companies. We want to comply with all applicable requirements, but understanding what requirements apply to us in various locations isn’t always easy.

The GDPR has brought this challenge front and center for us. We do not have any actual presence in any European countries. However, we do have customers in nearly all European countries, and are subject to some data privacy protections where those customers are located. That makes sense, and we want to be good citizens, but as with many other Internet based companies it can be daunting to figure out how the regulations apply to us.

Fortunately for us, the principles established in the GDPR are principles that we were already following in our normal practices. Our customers are businesses and providers of Internet based services, and for the most part we don’t provide services to individual end users. Additionally, our customers manage their own data, have full access to the information in our systems, and we don’t process or use the information they set up in our service beyond what they configure for their own use.

We did find that there were a few requirements related to the GDPR that, while our prior practices were basically already in compliance, weren’t clearly articulated in our Terms of Service or Privacy Policy. So, we’re updating both documents to more clearly set out how our policies and practices address these areas.  The updates will take effect on 2018-05-18

This includes more clearly stating that we are not collecting or processing data beyond what our customers configure to use for their monitoring. We only use contact information in our system to provide the monitoring you configure, and send the notifications you set up in the way you configure them. Our customers can download their own data whenever they want to. Beyond that, we don’t use or process information from our customers.

This is our normal practice, and applies to everyone. We don’t maintain a separate policy for customers in Europe.

Since we are a data processor, and the data is under the control of our customers who are themselves businesses providing services to others, for GDPR purposes we are a Processor rather than a Controller. Since we don’t have a presence in any EU countries, and we provide processing services to controllers in several EU countries, according to the guidelines published by the Article 29 Working Party, the lead supervisory authority will be the supervisory authority that is competent to act as lead for the controller.

If you are a data controller in a European country, or even if you aren’t, you may have questions about our systems that are necessary for you to comply with obligations you have in your location, and for your customers. If you have questions or concerns that aren’t addressed in our updated policies, please let us know.

UPDATE: We have now received our Privacy Shield certification, which required our Privacy Policy to be updated again to meet those requirements.   The most recent changes are aimed specifically at the certification requirements.  As always, you can see our current Privacy Policy and our Terms of Service on our web site.

Probe Server Changes [PY,NC]

The following probe servers will be changing IP addresses on 2018/04/03:

Cary, North Carolina (NC) – USA is changing from
( / 2607:fc50:0:15::3a0)
Charlotte, North Carolina (NC) – USA
( /2604:9980:0:12c:ec4:7aff:fecb:776c)

Philadelphia, Pennsylvania (PY) –  USA is changing from
( / 2604:bf00:210:1d::2)
( /2604:bf00:214::10)

Please adjust your firewalls appropriately if you whitelist so your checks do not fail because of the probe IP address changes.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ, a text file, and via DNS query,


[UPDATE – 2018-04-03 11:35GMT-6] – IP changes complete.

Probe Server Changes [UK,NL,NC,NJ,SG] and removal [ES]

The following probe servers will be changing IP addresses on 2018/02/07:

Manchester, England (UK) – GB is changing from
( / 2a06:8181:a0:bfaf::1)
Leeds, England (UK) – GB
( / 2a00:f9c0:0:405::12)

Amsterdam, Netherlands (NL) – NL is changing from
( / 2a00:d880:5:a0f::2)
( / 2a02:2770:5:0:21a:4aff:fe1a:c131)

Asheville, North Carolina (NC) – USA is changing from
( / 2605:a880:0:36::10)
Cary, North Carolina (NC) – USA
( / 2607:fc50:0:15::3a0)

Newark, New Jersey (NJ) – USA is changing from
( / 2001:19f0:1604:3ede:250:56ff:feae:67ec)
( /2607:fcd0:ccc0:1301::10)

Singapore (SG) – SG is changing from
( / 2001:df0:24f:214::10)
( /2400:8901::f03c:91ff:feb9:fbf4)

The following probe is being removed on  2018/02/07:
Madrid, Spain (ES) – ES
( / 2a02:4ac0::2002)

Please adjust your firewalls appropriately if you whitelist so your checks do not fail because of the probe IP address changes.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ, a text file, and via DNS query,

[UPDATE – 2018-02-07 10:35GMT-7] – IP changes and probe removal complete.

Cluster Check

Allow me to introduce our newest check type, Cluster.

The Cluster check allows you to group interdependent NodePing checks in order to get notifications and track availability of the group of checks as a whole. You specify a threshold of how many of those checks must be passing in order for the cluster to be considered ‘up’. If the number of those checks passing drops below your configured threshold, the cluster check will fail and send the configured notifications.

We use it to keep an eye on our Cassandra servers but you can use it for any logical group of services that are interdependent. Some other use cases:

  • DNS services – monitor each DNS server with DNS checks and then a cluster check on those DNS checks to get that very important alert when all DNS servers are offline!
  • Web servers – monitor the backend web servers behind your reverse proxy or load balancer to make sure you have enough of them available to handle the traffic.
  • SMTP – monitor your SMTP checks and know that there’s always at least one server available to receive email for your domains.

Cluster checks are available to all NodePing plans today. If you’re not using NodePing yet, please sign up for our 15-day, free trial today.


Banana image Designed by Daviles / Freepik

Probe Server Changes and Addition [IT,UK,CH,JP,CA,OR,GA]

The following probe servers will be changing IP addresses on 2017/12/05:

Manchester, England (UK) – GB is changing from
( / 2001:ac8:21::b0)
( / 2a06:8181:a0:bfaf::1)

Tokyo, Japan (JP) – JP is changing from
( / 2400:8900::f03c:91ff:fedb:b594)
( / 2406:d500:9::7a91:9b75)

Los Angeles, California (CA) – USA is changing from
( / 2607:f7a0:3:8:225:90ff:fe51:d0b0)
( / 2607:fcd0:106:ab01::10)

Portland, Oregon (OR) – USA is changing from
( / 2605:ea00:1:1:d267:e5ff:fee7:51c)
( / 2604:B480:FFF6::10)

Atlanta, Georgia (GA) – USA is changing from
( / 2607:f7a0:6:a:225:90ff:fe79:4318)
( / 2607:fcd0:aa80:2200::10)

We’re also adding a new server to the Europe region on 2017/12/05:
Zurich, Switzerland (CH) – CH
( / 2a06:c01:1:1102::9133:51)

The following probe is being removed on 2017/12/05:
Milan, Italy (IT) – IT
( / 2001:ac8:24::40)

Please adjust your firewalls appropriately if you whitelist so your checks do not fail because of the probe IP address changes.

An always current and updated list of all the IP addresses for our probe servers can be found in the FAQ, a text file, and via DNS query,

[UPDATE – 2017-12-05 10:53GMT-7] – IP changes and probe addition/removal complete.

The NodePing API and PowerShell

At NodePing we interact with our own API quite a bit from the command line.  Most of that is from bash on Linux, because that’s where we live most of our lives.  But the API works well from just about any scripting environment.  Since our documentation examples all use curl with bash syntax, it seemed like it might be a good idea to also write up some examples of using other tools.  Here, as the first installment of that effort, is a handful of examples of using PowerShell with the NodePing API.

Full disclosure: PowerShell is not an environment we spend a lot of time working with.  There are likely ways to do some of this better.  We’ve tested the example calls in this post.  Hopefully it is enough to get you started if you work with PowerShell.

Basic GET Calls

Basic calls are quite simple to make using Invoke-RestMethod.  If you have the check ID, getting a check is quite easy:

Invoke-RestMethod ‘[token]’

This returns a JSON object, which PowerShell handles easily.

_id : 201205050153W2Q4C-0J2HSIRF
description : This is the description, if the check has one.
public : False
customer_id : 201205050153W2Q4C
queue : nyI8JSL23W
interval : 1
created : 1427513104608
pro :
modified : 1510332098196
parameters : @{target=; follow=False; threshold=5; sens=2; invert=False; verify=false}
firstdown : 0
label : Keep me
runlocations : False
enable : active
uuid : bd3eha9o-z2m5-4qg2-9k8b-jqq0kiituyxz
state : 1
status : assigned
notifications : {}
type : HTTP
acctdisable : False
suspacct : False
dep : False

Note that “parameters” is another hash.  You can refer to the fields in the check as properties of the returned object, including properties that are hashes themselves.  So, for example, this will give you the check check threshold, which is part of “parameters”.

$check = Invoke-RestMethod ‘[token]’ ;

API Authentication

PowerShell doesn’t easily support basic authentication.  Since the NodePing API supports passing the token as a parameter, the easiest approach is to include it in the query string, as I did in the example above.  In most cases I prefer to pass it in the Body, as I’ll show in examples below.  If you’re working with a script its usually easiest to set a $token variable and use that throughout your script.  If you’re just sending a URL as I did in the simple GET calls above, actually putting in the query string works fine.

If you’re using the API in scripts that make several calls to the API, you might want a more reusable way to pass the token that keeps it out of your Body.  You can do this by manually building the headers.  That requires base64 encoding the credentials and then setting that using the -Headers argument. That looks something like this:

$hash = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $token,"")))

Then set the -Header argument to @{Authorization=(“Basic {0}” -f $hash)}

Or, if you are doing this several times, you will probably want to set this to a variable you can reuse.

Some sites suggest that you create a credential object using ConvertTo-SecureString and Management.Automation.PSCredential, and pass that using the -Credential argument.  However, this won’t work with the NodePing API, since the -Credential option waits for the challenge to send the authorization header.  The API is stateless, and expects the header on each request.

Put and Post Calls

We recommend that you use JSON to set fields for our API in most environments.  However, PowerShell does not automatically handle sending the body as JSON.  For POST calls, this isn’t a big deal, and you can just POST the body as it is and Invoke-RestMethod sends the data as if it were a form.  PUT and DELETE calls don’t work that way.  For those, you have to convert to JSON, or include all of your parameters in a query string.

Creating a check looks like this:

Invoke-RestMethod '' -Method Post -Body @{ 
    label='test label' 

This call will return an object with the new check.  You can add any of the other fields listed in our documentation.

Updating a check is almost the same.  This can all be done on one line, but we’ll split it out here to make it easier to see.

$data = @{ label='a new label'; type="HTTP"; interval=5; token=$token } | ConvertTo-Json
Invoke-RestMethod '' -Method Put -Body $data

Note that since we’re updating a check, we need to include the check ID.  As with the Post call, the Put call returns the updated check object.

Working with Lists of Checks

Working with a list of checks is slightly trickier.  The call returns a JSON object with a list of checks using the ID as the key.  For PowerShell, this is a hash table of hashes.  So to list checks, you would do something like this:

Invoke-RestMethod '' -Body @{ token=$token } | %{ $_.PSOBJECT.Properties.value }

This is actually fairly handy, because you can fairly easily list a specific field from the response.  For example, this lists all of the targets from all of the checks on this account:

Invoke-RestMethod '' -Body @{ token=$token } | %{ $ }

You could do all sorts of things at this point.  For example, here’s a list of all checks that include “nodeping” somewhere in the check’s target:

Invoke-RestMethod '' -Method Get -Body @{ token=$token } | %{ foreach($value in $_.PSOBJECT.Properties.value){ if($ -like "*nodeping*"){ $value } } }

This is practical as a way to find a check with a specific target up to a few thousand checks.

Getting Results

Applying the same principles should let you do just about anything with the NodePing API.  Applying the same pattern to a results call, for example:

Invoke-RestMethod '' -Method Get -Body @{ token=$token; limit=2; clean=1 }

Note that you’ll want to always include the “clean” parameter for results.  The unclean response takes more parsing.

The options available for results calls are documented here:


That’s the basics of using PowerShell to interact with the NodePing API.  With the API you can add checks, remove checks, get your results and uptime, manage contacts and notifications, and add and manage subaccounts.  Our customers use the API both for programmed integrations, and from the command line using quick scripts like the ones I demonstrated here to make quick changes to several (or lots) of checks at once.

If you’re doing interesting things with PowerShell and the NodePing API, we’d like to hear about it!  Please email support and let us know.  That’s also a great place to ask us questions.  We’re happy to help people interact with our service.