Security

Keep your monitoring setup secure.

Monitoring often touches production services and scheduled jobs. Follow these practices to protect your PingBeacons account, heartbeat URLs, and monitored infrastructure.

Most important rule

Treat every PingBeacons heartbeat URL like a secret credential. Anyone who obtains the complete URL may be able to send a heartbeat to that monitor.

1. Protect heartbeat URLs

Every heartbeat monitor uses a unique URL containing a token. Your scheduled job uses this URL to tell PingBeacons that it completed.

Keep the complete URL private

Do not share the real heartbeat URL unless the receiving system genuinely needs it.

Avoid accidental exposure

Check screenshots, support messages, documentation, logs, and code before publishing them publicly.

Why does this matter?

A heartbeat tells PingBeacons that a scheduled job contacted the monitor. An exposed URL could allow someone else to send requests to that heartbeat endpoint.

2. Never commit heartbeat URLs to public Git repositories

Avoid placing a real heartbeat URL directly inside source code that could be published or shared.

Avoid

curl -fsS "https://api.pingbeacons.com/h/REAL_SECRET_TOKEN"

Prefer an environment variable

PINGBEACONS_HEARTBEAT_URL="YOUR_HEARTBEAT_URL"

Your script can then read the value from its environment.

curl -fsS "$PINGBEACONS_HEARTBEAT_URL"
Environment files also need protection

Do not commit production environment files containing secrets to a public repository. Restrict access to them on the server.

3. Do not expose heartbeat URLs in frontend code

A secret placed in browser-side JavaScript is not private. Users can inspect network requests, JavaScript bundles, and page source.

Client-side code

Do not place heartbeat URLs inside public React, Next.js browser code, HTML, or other client-side assets.

Server-side jobs

Send heartbeats from the server, cron job, worker, backup process, or scheduled script that actually performs the work.

4. Use safe monitoring endpoints

Website and API monitors repeatedly request the configured target. Choose endpoints that are safe to call as part of normal monitoring.

Good monitoring target

A read-only health, status, website, or API endpoint that can be safely requested multiple times.

https://api.example.com/health

Avoid side effects

Do not monitor an endpoint that creates data, sends email, charges a payment, deletes records, or performs another action every time it receives a request.

5. Do not put credentials in monitor URLs

Avoid embedding usernames, passwords, API keys, access tokens, or other application secrets directly in a monitored URL.

https://api.example.com/health?api_key=SECRET_KEY
Prefer a dedicated health endpoint

When possible, expose a minimal endpoint that reveals only the information necessary to determine whether the service is healthy.

6. Protect your PingBeacons account

Use a strong, unique password

Do not reuse your PingBeacons password on another website or service.

Protect your email account

Your email is important for verification, password recovery, and monitoring communication.

Keep account information current

Make sure important notifications continue reaching an email address you control.

7. If a heartbeat URL is exposed

Treat an accidentally published heartbeat URL as compromised rather than assuming nobody noticed it.

1

Remove the exposed value

Remove it from the public page, repository, screenshot, log, or other location where it was exposed.

2

Remember that deletion may not be enough

Git history, caches, mirrors, screenshots, or third-party systems may still contain a previously published value.

3

Replace the exposed heartbeat URL

When heartbeat token rotation or regeneration is available, replace the exposed URL with a fresh one and update the job using it.

8. Production checklist

Heartbeat URLs are server-side only

No real heartbeat tokens are exposed in public browser code.

Secrets are not committed publicly

Production credentials and environment files are excluded from public source control.

Monitoring endpoints are safe

Repeated monitoring requests cannot trigger destructive or sensitive actions.

Account credentials are protected

Your account uses a strong unique password and an email address you control.

Next steps