Skip to content

Lightweight uptime notification system build on top of Vercel's edge network.

Notifications You must be signed in to change notification settings

openstatusHQ/vercel-edge-ping

Repository files navigation

OpenStatus | Vercel Edge Ping

No library. No UI. No maintenance.

We want to provide you a lightweight version of OpenStatus to monitor your services.

Therefore, we will be using Vercel's edge runtime to monitor your services across 18 regions as simple as possible. Read more about vercel edge network regions.

Choose your configuration and be ready in 5min to monitor your website or API services.

You can even one-click self-host the service by adding the stringified array to the REQUESTS environment variables. (see here)

Deploy with Vercel

Currently supported notification channels are:

  • Slack
  • Discord
  • Campsite
  • Telegram

Getting Started

To work/test it locally:

pnpm install
pnpm start

Vercel CLI

Make sure to have the Vercel CLI running on your machine. When you first start the project, you will get asked to connect it to your vercel account.

Checkout .env.example for the (required) environment variables. Use the Vercel CLI and the add env command:

vercel env add

Tinybird CLI (optional)

If you want to ingest the data and keep track of the response times, add the TINYBIRD_TOKEN to your environment variables.

Include the Tinybird CLI as well to easily set the pipe and datasource to ingest and get the data:

python3 -m venv .venv
source .venv/bin/activate
pip install tinybird-cli
tb auth -i

Add --dry-run to the commands if you want to first test them:

tb push tb/datasources/http_ping_responses.datasource
tb push tb/pipes/endpoint__get_http.pipe

Configuration

Monitors

A PingRequest includes the below props:

Property Type Description
url string The URL to send the ping request to.
method string The HTTP method to use for the request (e.g., GET, POST).
body? string Optional request body.
headers? Record<string, string> Optional headers to include in the request.
timeout? number Optional timeout in milliseconds for the request. Defaults to 50_000ms.
prewarm? boolean Optional flag to prewarm the endpoint before timing the next request.

There are multiple ways to add your monitors:

  • via ./api/resources.json file but that would require a fork + changes
  • via a fetch call using the REQUEST_GET_URL returning a type of PingRequest[] but that would require you to maintain that connection
  • via .env where we stringify the PingRequest[] array and read it out

All three options can work parallely.

We roughly validate the external input. If they don't match the expected type, you'll see a console.error in your logs.

File reading

Add your endpoints statically to the list ./api/resources.json file.

For example:

[{ "url": "https://openstat.us/200", "method": "GET", "prewarm": true }]

Fetching resources

Create an endpoint that returns the list. Use the EXTERNAL_REQUESTS_URL to fetch the list dynamically on every ping.

To secure your endpoint, we provide the EXTERNAL_REQUESTS_SECRET environment variable that gets passed as property to the header Authorization: Bearer EXTERNAL_REQUESTS_SECRET.

Environment variables

The fastest way to get started without having to commit any code changes is to add the stringified list to your environment variables.

For example:

[{"url":"https://openstat.us/200","method":"GET", "prewarm":true}]

Note

Whenever you change the environment variable, you'll need to rebuild/redeploy the app to included the latest changes.

vercel.json

We have made some configurations within vercel.json. Let's break them down.

The maximum duration of the serverless functions are set to the max of the free plan:

  "functions": {
    "api/cron.ts": {
      "maxDuration": 60
    }
  }

The cron jobs are set to the maximum of the free plan which is daily:

  "crons": [
    {
      "path": "/api/cron",
      "schedule": "0 0 * * *"
    }
  ]

If you are on a pro plan, update it to the cron expression you'd like to use.

The cron endpoint is automatically secured by including the CRON_SECRET environment variable.

GitHub Workflows (optional)

Optionally, if you want to keep the vercel free plan and increase the periodicity of the cron job, you can work it out by using github actions.

Go to your GitHub repository → Settings → Secrets and variables → Actions → New repository secret and add:

  • CRON_SECRET - the same one as in vercel envs
  • BASE_URL - the production URL from vercel

You can either trigger it manually via workflow_dispatch or uncomment and update the schedule.cron to the cron expression you'd like to periodically run the attached curl.

Notification Channels

If set, we will send a message if >50% of the regions of a specific endpoint are failing. An endpoint fails, if the response status code doesn't start with 2 or 3.

Notifications to the different services will be send only if the environment variables are set.

Slack Webhook (optional)

If you want to get notified whenever an endpoint is not healthy, add the SLACK_WEBHOOK_URL to your environment variables.

To create a webhook for a specific channel you'd like to post the messages to, follow the guide.

Discord Webhook (optional)

If you want to get notified whenever an endpoint is not healthy, add the DISCORD_WEBHOOK_URL to your environment variables.

To create a webhook for a specific channel you'd like to post the messages to, follow the guide.

Campsite Post (optional)

If you want to get notified whenever an endpoint is not healthy, add the CAMPSITE_API_KEY and CAMPSITE_CHANNEL_ID to your environment variables.

To create an API key, follow the docs. You will need to connect your integration to a channel and copy the channel id as well.

Telegram Bot (optional)

If you want to get notified whenever an endpoint is not healthy, add the TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID to your environment variables.

To create a telegram bot, follow the gist.

Deployment

Check the Vercel CLI docs regarding deploy commands if you want to learn more. Otherwise:

# deploy to preview
vercel
# deploy to production
vercel --prod

More

Note

If you host your services on Vercel and want to make sure the provider is up, this is a bad idea as the edge ping depends on Vercel itself. Instead, it is good to keep uptime of your own services like hosted APIs, getting latency over time, or be informed whenever your services are not responding as expected.

If you are on a pro plan on vercel, you are allowed for Unlimited cron invocations instead of Triggered once a day. Fork and change the vercel.json content to whatevery cron you'd like to. Use crontab.guru to quickly edit and validate the cron expression.

Test the notifications with openstat.us where you can define the returned status code with ease.

About

Lightweight uptime notification system build on top of Vercel's edge network.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published