Introduction
In this article, we will demonstrate how to use the Ddosify GitHub Action to periodically test the latency of our target endpoints from 60+ cities worldwide. By configuring the action to run on a schedule, we can ensure that the performance of our locations is consistently monitored. If the latency of any of our locations exceeds the expected value, we will receive an email notification alerting us to the issue. By using this action, we can proactively identify and address potential performance issues before they impact our users.
Prerequisites
- Ddosify API Key. Here are the instructions to create one.
- A GitHub repository to store the workflow file.
Step 1: Store the Ddosify API Key as a Secret
To store the Ddosify API key as a secret, follow these steps:
- Copy the Ddosify API key from the Ddosify Cloud account settings page.
- Go to the repository settings page.
- Click on the
Secrets-Actionstab. - Click on the
New repository secretbutton. - Enter
DDOSIFY_API_KEYas the name of the secret. - Enter the Ddosify API key as the value of the secret.
- Click on the
Add secretbutton.
Step 2: Create a Workflow File
Create a new file named ddosify-latency-testing.yml in the .github/workflows directory of your repository. Different configurations are available in this repository.
name: "Ddosify Latency Testing"
on:
schedule:
- cron: "0 * * * *" # Every one hour. The shortest interval is once every 5 minutes
jobs:
latency-test:
runs-on: ubuntu-latest
steps:
- name: Ddosify Latency Test
uses: ddosify/ddosify-latency-action@v1
with:
api_key: ${{ secrets.DDOSIFY_API_KEY }}
target: "https://app.servdown.com"
locations: '["*"]'
failIf: "EU.*>50"
The on section defines the event that triggers the workflow. In this example, the workflow is scheduled to run every hour. The uses section defines the action to run. In this example, we use the ddosify/ddosify-latency-action@v1 action. The with section defines the inputs to the action. In this example, we define the following inputs:
api_key: The API key to authenticate with Ddosify. We use the GitHub Secrets feature to store the API key. The API key is stored in theDDOSIFY_API_KEYsecret.target: The target endpoint to test. You can use any valid URL or IP address.locations: The locations to test. In this example, we use["*"]to test all the 60+ cities worldwide. We will show the usage examples of thelocationsobject on the locations section.failIf: The condition to fail the test. In this example, we useEU.*>50to fail the test if the latency of any city onEuropecontinent exceeds 50ms. We will show the usage examples of thefailIfobject on the failIf section.
After you push the workflow file to the repository, the workflow will be triggered. You can check the workflow status on the repository actions page. An example output of the workflow is shown below.
This actions is failed because the latency of the EU locations exceeds the expected value.
You can check the detailed results of the test on the repository action page. You must be logged in to the GitHub to view the logs.
Input Examples
locations
The following table shows some examples of the locations input. Supported locations are accessible via Ddosify API or you can get the location codes from the example output. We suggest accessing it from Ddosify API since we are adding new locations continuously. You can use the locations input to test the latency of your target endpoint from a specific locations.
| Example | Description |
|---|---|
'["*"]' | All over the world (60+ cities) |
'["NA.*"]' | All the available cities from North America (NA) Continent |
'["EU.DE.*"]' | All the available cities from Germany |
'["EU.GB.ENG.LO"]' | From London |
failIf
The following table shows some examples of the failIf input. You can use the failIf input to fail the test if the latency of any location exceeds the expected value. The failIf input supports the following examples:
| Example | Description |
|---|---|
"any>100" | Fail if any of the locations is greater than 100ms latency |
"EU.*>80" | Fail if any of the locations from Europe (EU) Continent is greater than 80ms latency |
"NA.US.TX.*>120" | Fail if any of the locations from Texas is greater than 120ms latency |
"NA.US.TX.DA>120" | Fail if Dallas is greater than 120ms latency |
Example Output
The following table shows an example output of the action. You can access the location codes from this table or from the Ddosify API. The Fail If column shows the condition to fail the test. The test is failed if the latency of any location exceeds the expected value. In this example, the test is failed because the latency of the Europe locations exceeds the expected value.
Fail if: EU.*>100
Target: https://app.servdown.com
Locations: *
┌────────────────────────────────────────────────────────────────────────────────────┐
| Location | Location Code | Status Code | Latency (ms) | Fail If (ms) |
├────────────────────────────────────────────────────────────────────────────────────┤
| Las Vegas | NA.US.NV.LV | 200 | 196 | |
| Oslo | EU.NO.OS | 200 | 63 | >100 |
| Boston | NA.US.MA.BO | 200 | 126 | |
| Seoul | AS.KR.SE | 200 | 288 | |
| Istanbul | AS.TR.IS | 200 | 56 | |
| Cape Town | AF.ZA.WC.CT | 200 | 169 | |
| San Antonio | NA.US.TX.SA | 200 | 138 | |
| Denver | NA.US.CO.DE | 200 | 154 | |
| Hamburg | EU.DE.HA.HA | 200 | 28 | >100 |
| Chicago | NA.US.IL.CH | 200 | 116 | |
| Hyderabad | AS.IN.TG.HY | 200 | 145 | |
| Salt Lake City | NA.US.UT.SLC | 200 | 139 | |
| Amsterdam | EU.NL.NH.AM | 200 | 31 | >100 |
| Hong Kong | AS.CN.HCW.HK | 200 | 205 | |
| Minneapolis | NA.US.MN.MI | 200 | 117 | |
| Sao Paulo | SA.BR.SA | 200 | 231 | |
| Denizli | AS.TR.DE | 200 | 81 | |
| Sydney | OC.AU.NSW.SY | 200 | 313 | |
| Dublin | EU.IE.L.DU | 200 | 35 | >100 |
| New Delhi | AS.IN.DL.ND | 200 | 272 | |
| Lappeenranta | EU.FI.SK.LA | 200 | 55 | >100 |
| Stockholm | EU.SE.ST | 200 | 32 | >100 |
| Des Moines | NA.US.IA.DM | 200 | 127 | |
| Los Angeles | NA.US.CA.LA | 200 | 184 | |
| Montreal | NA.CA.QC.MO | 200 | 114 | |
| Pune | AS.IN.MH.PU | 200 | 139 | |
| Houston | NA.US.TX.HO | 200 | 131 | |
| Johannesburg | AF.ZA.GP.JO | 200 | 189 | |
| Miami | NA.US.FL.MI | 200 | 158 | |
| New York | NA.US.NJ.NY | 200 | 96 | |
| Dallas | NA.US.TX.DA | 200 | 162 | |
| Melbourne | OC.AU.VIC.ME | 200 | 310 | |
| Philadelphia | NA.US.PA.PH | 200 | 102 | |
| Quincy | NA.US.WA.QU | 200 | 163 | |
| Toronto | NA.CA.ON.TO | 200 | 114 | |
| Frankfurt | EU.DE.HE.FR | 200 | 21 | >100 |
| Milan | EU.IT.25.MI | 200 | 44 | >100 |
| Taipei | AS.TW.TP | 200 | 268 | |
| Warsaw | EU.PL.MZ.WA | 200 | 28 | >100 |
| Ankara | AS.TR.AN | 200 | 62 | |
| Mumbai | AS.IN.MH.MU | 200 | 145 | |
| North Charleston | NA.US.SC.NC | 200 | 112 | |
| Doha | AS.QA.DA.DO | 200 | 132 | |
| Seattle | NA.US.WA.SE | 200 | 160 | |
| Atlanta | NA.US.GA.AT | 200 | 118 | |
| Paris | EU.FR.IDF.PA | 200 | 64 | >100 |
| Ashburn | NA.US.VA.AS | 200 | 97 | |
| London | EU.GB.ENG.LO | 200 | 34 | >100 |
| Kansas City | NA.US.MO.KC | 200 | 127 | |
| Jakarta | AS.ID.JK | 200 | 275 | |
| Tel Aviv | AS.IL.TA | 200 | 88 | |
| Phoenix | NA.US.AZ.PH | 200 | 191 | |
| Manama | AS.BH.MA | 200 | 127 | |
| Madrid | EU.ES.MA | 200 | 53 | >100 |
| Osaka | AS.JP.OS | 200 | 243 | |
| Izmir | AS.TR.IZ | 200 | 61 | |
| Dublin | NA.US.OH.DU | 200 | 106 | |
| Tokyo | AS.JP.TO | 200 | 270 | |
| Portland | NA.US.OR.PO | 200 | 178 | |
| Dubai | AS.AE.DU | 200 | 131 | |
| Singapore | AS.SG.01.SI | 200 | 167 | |
| Santiago | SA.CL.RM.SA | 200 | 215 | |
| Zurich | EU.CH.ZH | 200 | 26 | >100 |
| San Jose | NA.US.CA.SJ | 200 | 174 | |
Conclusion
The latency is important for the user experience. You should test your target endpoint's latency periodically to ensure that your users are not experiencing any issues. You can use Ddosify Latency Testing GitHub action to test the latency of your target endpoint periodically. The action will send a request to your target endpoint from 60+ cities and measure the latency. If the latency is higher than the threshold, the action will send a notification to you. So you can take action to fix the issue before your users experience any problems. If you don't want to use Github Actions, you can also use Ddosify Cloud to create periodic city-level latency tests. An example scheduler result for latency testing in Ddosify Cloud is shown below.
Share on social media: