StillOnline?

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.

ComponentExample check URL
Webhook ingressGET https://hooks.product.com/health
Event APIGET 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.

  1. Docs / onboarding: Status: https://stillonline.tech/s/demo
  2. During delivery lag: update the page using the incident post template
  3. Subscribe with Google on the public page for email updates
  4. 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.

MonitorDo not monitor
Your receiver returns 200 on healthEach subscriber’s localhost callback
Your queue consumer health if exposedThird-party SaaS (use their status page)
Signing secret rotationIndividual delivery retries per tenant

Partial degradation (“some events delayed”) may need a manual incident post even when health is green.

Setup in five steps

  1. Ship GET /health on the webhook host — health quickstart.
  2. StillOnline → project → check.
  3. Publish status link in docs — public status page guide.
  4. Connect Telegram for owner alerts — Free: one channel; Pro / Ultimate: email, Telegram, and Slack.
  5. B2B sales: mention status URL in security questionnaire — B2B trust guide.

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.

Further reading