Every PR you ship spawns a preview deploy. Each one is a URL that might break in 50 different ways before your reviewer clicks it. Valpero can watch every preview automatically: each deploy creates a 5-minute HTTP monitor that lives for 24 hours, then deletes itself.
No alert fatigue (push/email are off for these monitors). No manual cleanup. Just a quiet "preview was 200 OK, response 89 ms" line in your dashboard.
Step 1 — Get your webhook URL
- Open Dashboard → Integrations → Preview deploys.
- You'll see three URLs — one each for Vercel, Netlify, and a generic GitHub Actions endpoint:
https://valpero.com/api/integrations/deploy/vercel?t=<your-token>
https://valpero.com/api/integrations/deploy/netlify?t=<your-token>
https://valpero.com/api/integrations/deploy/github?t=<your-token>
The token is per-account and stable — copy whichever URL you need.
Step 2 — Wire it in
Vercel
- Vercel dashboard → Project → Settings → Git → Webhooks.
- Add a new webhook with the Vercel URL above.
- Choose the events:
deployment.created,deployment.succeeded. - Save.
That's it. On every preview deploy, Vercel POSTs us the deploy URL and we spin up a 24-hour monitor.
Netlify
- Netlify → Project → Build & deploy → Deploy notifications.
- Add notification → Outgoing webhook.
- Event: Deploy succeeded. URL: paste the Netlify URL above.
- Save.
Netlify sends us deploy_ssl_url, we use that as the monitor target.
GitHub Actions / generic CI
If you control the deploy step yourself, just curl us at the end of
the workflow:
- name: Notify Valpero of preview
if: always()
run: |
curl -X POST "https://valpero.com/api/integrations/deploy/github?t=${{ secrets.VALPERO_DEPLOY_TOKEN }}" \
-H "Content-Type: application/json" \
-d '{
"deployment_status": { "state": "success", "environment_url": "${{ steps.deploy.outputs.url }}" },
"deployment": { "environment": "preview-${{ github.event.number }}" },
"repository": { "full_name": "${{ github.repository }}" }
}'
Drop the token into your repo secrets as VALPERO_DEPLOY_TOKEN.
What gets monitored
Each ephemeral monitor:
- Type: HTTP, GET, follow redirects, 10 s timeout.
- Interval: 5 minutes (we don't run cloud probes harder than that for ephemeral preview URLs).
- Region: whichever is closest to the preview, single region.
- Notifications: email/Telegram/Slack are off. The monitor is just a signal in your dashboard.
- Status page: hidden by default.
- Lifetime: 24 hours. After that we silently delete it. If a new webhook fires for the same preview within 24h, the monitor is refreshed (the 24h clock starts over).
You'll see them in your dashboard with an "ephemeral" badge and the source label (Vercel / Netlify / GitHub).
Catching a broken preview
If a preview returns 5xx or doesn't respond, the ephemeral monitor shows DOWN like any other monitor. Push notifications are muted by default to avoid spam, but you can flip that on per-monitor in the dashboard if you want a phone alert when a preview breaks.
Common questions
Will it count against my plan limit? Yes — ephemeral monitors are counted just like normal ones. If you're on Free (1 monitor) you'll hit the limit immediately. The integration makes most sense from Start (5 monitors) and up.
Can I disable email/push for ephemeral monitors specifically? They're off by default. You can re-enable per-monitor in the dashboard if you want.
The monitor wasn't created. Check the integrations dashboard — we log the most recent webhook payloads we received. If the source's "deploy succeeded" event doesn't include a URL, we skip it.
The token leaked. Open the integrations page → Rotate token. Old webhook URLs stop working immediately.
When to use this
- You ship preview URLs to designers / non-engineers and want to know before they click that the build is broken.
- You're A/B-testing Lambdas or edge functions and want a paper trail of which preview was up when.
- You want a global health spot-check on each preview from a region outside your CI's run host.
When NOT to use this
If your previews are short-lived (under 10 minutes), the ephemeral monitor barely runs before it expires. For super-short feedback loops, add a deploy-time smoke test to your CI itself — Valpero is for "is it still up an hour later".