Create your own monitor with custom code

Latency, in literal terms of network performance at least, is the total amount of time to connect between devices. We usually call this the Round Trip Time or RTT for short. But sometimes there is more information behind that RTT number. You might be wondering what the CPU load is on a particual node that seems sluggish, or have other metrics that your remote may depend upon to remain healthy.

Jobs can help you do just that. By default, we expose the Deno runtime throughout our platform which allows you to script and run just about anything you can imagine.

Ok, enough talk. Let's run some code:

Creating workers via CLI

To test any script you can specify an entrypoint like so:

latency dev ./myapp.js

You can also add any script onto the default latency command at any time:

latency https://google.com --with=./my-temp-app.js

And you will see the output of your job along with the defaults.

Caveats

While running custom workers on your own has no limitations (with the exception of flags you specify) there are a few in-place for our cloud runtime. Workers started within our cloud will not have the following access:

• LAN, this will not work with the exception of localhost/127.0.0.1 being a loopback
• FFI - FFI currently does not support a way to handle specific security restrictions

Ensure you are using our secure binary as the insecure version does not have permission limitations

Secure latency cli will only run with the maximum permissions you set based on Deno's flags (see more @ deno).