Uptime monitoring for Shopify app backends
A Shopify app is not just an embedded UI — merchants depend on your OAuth callback, webhook ingestion, and compliance endpoints (including GDPR webhooks) staying up. Shopify’s partner dashboard shows install stats; it does not replace an external check on the HTTPS routes your app must answer, and it does not give merchants a neutral status link when your sync or billing integration fails.
StillOnline probes your public health URL and critical routes you register, hosts a status page for merchant-facing communication, and sends owner alerts via the StillOnline Telegram bot, Slack, or email.
Quick answer
Shopify app backends must answer OAuth callbacks, webhooks, and mandatory compliance webhooks over HTTPS. Monitor a public GET /health on your app’s production domain returning 200 when traffic can be served — register it in StillOnline (Free: one URL, five-minute checks; pricing). Show Payments or Sync on the status page during checkout incidents — public status page guide.
What Shopify app backends need
| Route / concern | Monitor how | Status page component |
|---|---|---|
| App URL / API health | GET /health → 200 | API or App backend |
| OAuth install callback | Usually covered by same host health | Authentication (if separate outage) |
Webhook ingestion (/webhooks/shopify) | Separate check if different host — webhook platform guide | Webhooks or Sync |
| GDPR mandatory webhooks | Same ingestion host or dedicated path returning 2xx | Compliance |
| Shopify platform outage | Inform only — use Shopify status | Third-party: Shopify degraded, not your major outage |
Do not promise features Shopify or StillOnline do not ship — document today’s behavior only.
Step 1 — Health route on your app host
Host on Railway, Fly, Lambda, or similar — pattern is the same: lightweight /health, no session required on that path.
curl -sS https://your-app.example.com/health
Webhook paths often return 401 without HMAC — do not register raw webhook URLs as generic 200 checks unless you have a test mode. Use /health for liveness; add webhook monitoring deliberately — webhook platform status page.
Step 2 — StillOnline setup
- Sign in.
- New project → merchant-facing product name.
- HTTP check → production health URL, GET, 200.
- Publish status page link in app listing support docs, partner FAQ, or incident emails — not buried in footer only.
Connect Telegram in settings — Telegram guide.
Free: one URL, one alert channel. Pro / Ultimate: more checks and all channels — pricing.
What merchants see during incidents
When checkout or inventory sync fails, merchants search for a status link. A hosted StillOnline status page with components like API, Webhooks, and Billing reads clearer than a generic “we’re down” tweet — incident post template.
If Stripe or Shopify is degraded but your servers are fine, label third-party components as Degraded in incident posts rather than claiming a full outage — incident post template.
Related guides
- Health check URL quickstart
- Webhook platform status page
- B2B status page trust
- Telegram owner alerts
FAQ
Should StillOnline monitor my Shopify App Bridge frontend only?
Usually no — monitor the backend health URL merchants’ shops call. Embedded admin UI can load while webhooks fail. Free allows one URL — register API health — API-only guide.
Can StillOnline check /webhooks/shopify with a normal GET?
Shopify webhooks expect signed POST bodies — a naive GET may return 404 or 405. Use /health for uptime; add dedicated webhook monitoring only with a test endpoint that returns 200 — webhook platform guide.
Does StillOnline offer a custom domain for merchant status pages?
StillOnline hosts at stillonline.tech/s/{id}. Share that link in app support docs and during incidents — custom hostname for status pages is not part of the product. See public status page guide.