Status page for webhook platforms and event delivery
If your product receives or delivers webhooks, customers judge reliability by whether your ingress URL answers — not by whether your queue dashboard looks busy. When delivery lags, they open support tickets unless you already gave them a public status page and honest incident text.
StillOnline monitors your public HTTPS health endpoint, publishes a hosted status page for subscribers, and alerts you via email, Telegram (StillOnline bot), or Slack. You do not monitor each customer’s callback URL — only the infrastructure edge you control.
Quick answer
StillOnline monitors your public webhook or health HTTPS endpoint (for example https://hooks.yourproduct.com/health), publishes a status page for subscribers, and alerts owners via email, Telegram (StillOnline bot), or Slack. You do not monitor each customer’s callback URL — only your infrastructure edge.
What to put on the status page
Buyers of webhook platforms care about ingress and API availability first. StillOnline Free allows one URL per project — usually the health route on your webhook host. Split API and ingress into separate checks on Pro when you need component-level clarity.
| Component | Example check URL |
|---|---|
| Webhook ingress | GET https://hooks.product.com/health |
| Event API | GET https://api.product.com/v1/health |
| Dashboard (optional) | Marketing/app URL if it blocks purchases |
Deep dive on API-only products: API-only SaaS monitoring.
Customer communication
Integrators will not hunt for a status page while webhooks are already failing. Share the StillOnline URL before an incident—in docs, onboarding, or security questionnaires—so people know where to look when delivery lags.
- Docs / onboarding:
Status: https://stillonline.tech/en/s/{id} - During delivery lag: update the page using the incident post template
- Subscribe with Google on the public page for email updates
- You get Telegram DMs from the StillOnline bot when checks fail — Telegram guide
Webhook-specific honesty
External monitors prove your receiver returns 200 on a health path. They cannot see whether tenant #42’s localhost callback is reachable — that stays in your delivery logs and support process.
| Monitor | Do not monitor |
|---|---|
| Your receiver returns 200 on health | Each subscriber’s localhost callback |
| Your queue consumer health if exposed | Third-party SaaS (use their status page) |
| Signing secret rotation | Individual delivery retries per tenant |
Partial degradation (“some events delayed”) may need a manual incident post even when health is green.
Setup in five steps
- Ship
GET /healthon the webhook host — health quickstart. - StillOnline → project → check.
- Publish status link in docs — public status page guide.
- Connect Telegram for owner alerts — Free: one channel; Pro / Ultimate: email, Telegram, and Slack.
- B2B sales: mention status URL in security questionnaire — B2B trust guide.
Related guides
FAQ
Should StillOnline probe my customer webhook POST endpoint?
No. Register a GET /health route on your ingress host; StillOnline does not sign or replay customer webhook payloads. Design the health URL first — health check quickstart.
How do integrators verify StillOnline webhook platform uptime in code?
GET https://api.stillonline.tech/v1/public/status/{project-id} returns JSON without an API key — REST guide. Share the human status page in docs and onboarding.
Does StillOnline deliver or retry my customers’ outbound webhooks?
No. StillOnline monitors your HTTPS endpoints and publishes status; event delivery stays in your queue or worker stack.
Is StillOnline Free enough for a webhook SaaS MVP?
Yes — one project, one URL (usually ingress health) plus a public status page on Free. More components need Pro — Pricing.
Can AI agents check StillOnline status for a webhook platform?
On Pro, use StillOnline MCP or public JSON. Founders still get owner alerts via the StillOnline Telegram bot, Slack, or email — Telegram guide.