How to run a status page for your Shopify app

To run a status page for a Shopify app, list the parts of your app merchants rely on as components, monitor each one with an automatic health check, post an incident as soon as something breaks, update it at regular intervals until it is resolved, and link the page from your support widget and help center so merchants find it before they write in. During an outage, one public update replaces many identical “is it just me?” messages.

This guide covers why a Shopify app needs a status page, what to monitor, how to write incident updates, where the page should live and how to choose a tool.

Why does a Shopify app need a status page?

A Shopify app needs a status page because when it breaks, many merchants notice at once and most of them ask the same question. Without a public page, your team answers that question one conversation at a time while also trying to fix the problem.

A status page does three jobs:

• It answers “is it just me?” once, publicly. Merchants who check the page do not need to write in.
• It keeps your team focused on the fix. Fewer duplicate conversations means more time on the actual problem.
• It shows your track record. A history of uptime and resolved incidents tells merchants how you handle problems.

The goal is not a perfect record. Every app has bad days. The goal is that merchants hear about a problem from you, clearly and early, rather than discovering it in their store.

What should a Shopify app status page show?

A Shopify app status page should show each part of your app merchants depend on, its current health, any active incident with timestamped updates, and a history of uptime. Four elements cover it:

Pick components merchants would recognise. “Storefront booking widget” means more to a merchant than “edge worker cluster”. Four to six components is enough for most apps.

What should you monitor for a Shopify app?

Uptime monitoring for a SaaS app means checking a dedicated health URL for each part users rely on every few minutes, and marking a service down only when it fails its real job. For most Shopify apps, those parts are:

1. The app’s admin screens, the embedded app merchants open in the Shopify Admin.
2. Anything on the storefront, such as a widget, an app block or a script your app adds.
3. Your API or backend, including webhook processing from Shopify.
4. Background jobs that merchants depend on, such as syncs or scheduled emails, through a health endpoint that reports on them.

Use a dedicated health-check URL for each, such as https://api.yourapp.com/health, that returns a success code only when the service can actually do its job. A homepage that loads while the database is down tells you nothing.

In Convot, each status component can monitor an HTTPS URL. Convot checks it every 2, 5, 10, 15 or 30 minutes (5 by default), records a response in the 2xx range as up, and anything else as down. The URL must be public, because the monitor does not send credentials, so expose a health route that needs no login.

How do automatic incidents work?

Automatic incidents open when monitoring sees a service stay down, and close when it recovers, so the page stays accurate even when nobody has time to update it. Teams that update a status page by hand in the middle of an outage often forget, which leaves the page green while merchants see errors.

In Convot, a continuous stretch of failed checks opens an incident on the public page, marked as auto-generated, and resolves it when the URL responds again. You can also have Convot email your team when monitoring opens or resolves an incident; those alerts are for auto-detected incidents only, not ones you post by hand.

An automatic incident is a starting point. Add a human update as soon as you know more, because “Investigating” from a monitor tells merchants less than a sentence from you.

How do you post an incident update?

Post an incident update by naming what is affected, saying what you know and saying when you will update next, and label it with one of four statuses: Investigating, Identified, Monitoring or Resolved.

Set the impact honestly, from minor (most merchants unaffected) to critical (the app is broadly unavailable), and tick the components involved. Post the first update within minutes, even if all you can say is that you are looking into it.

How do you communicate an outage to customers?

To communicate an outage to customers, post within minutes, say what is affected, say what you know, and promise a time for the next update, then move through the four statuses in short, plain updates. An illustrative sequence for a storefront widget problem:

1. Investigating: “Some stores are not showing the booking widget. We are looking into it and will update within 30 minutes.”
2. Identified: “A change we released this morning broke the widget on themes using a specific layout. We are rolling it back.”
3. Monitoring: “The rollback is live and the widget is showing again on affected stores. We are watching to confirm.”
4. Resolved: “Fixed. The widget was missing for about 90 minutes on some stores. We have added a check so this kind of change is tested on more themes before release.”

Avoid vague phrases such as “some users may be experiencing issues”. Merchants want to know whether it affects them and what to do. If there is a workaround, say it.

How should you write the incident summary afterwards?

Write a short summary once the incident is resolved: what happened, how long it lasted, who was affected and what you are changing so it does not happen again. Keep it to a few sentences and skip internal blame.

A useful incident summary has four parts:

• What happened, in merchant terms.
• When it started and ended, with time zones.
• Who was affected, such as stores on a certain plan or theme.
• What you changed, so merchants know it was taken seriously.

Put the summary in the final update on the incident, so the history on your status page tells the whole story.

Where should merchants find your status page?

Merchants should find your status page from the places they already go for help: your support widget, your help center and your app’s own screens. A status page on a separate address nobody knows about only helps the merchants who already have it bookmarked.

In Convot, each app’s status page is part of its public site, on the same convot.help subdomain or custom domain as the help center, changelog and roadmap. The widget can show a Status section that links to the page with the line “Check current uptime and incidents”, so a merchant about to write in can check first. The status page and the widget section are both off by default: turn on the status page for the app first, then the widget toggle. During a big incident, also pin a short note in your help center and reply to new conversations with the link.

Convot’s status page does not offer email subscriptions yet, so merchants check the page or follow the link from the widget. If email or SMS alerts for merchants matter to you, a dedicated status tool may suit you better.

How does a status page reduce support load during an outage?

A status page reduces support load during an outage when merchants can find it quickly and it says something useful. Merchants who see an active incident describing their problem usually wait for the fix instead of writing in, and the ones who do write in can get a one-line reply with the link.

A status page cuts support load most when you do four things:

1. Post the incident before the conversations arrive, which automatic monitoring helps with.
2. Use the same words merchants use, so they recognise their problem.
3. Reply to related conversations with the link and the next update time, rather than a separate explanation each time.
4. Close the loop when it is fixed, by replying in the conversations that came in during the incident.

The guide to reducing support tickets with self-serve support covers the same idea for everyday questions.

How do you read the uptime history?

Read the uptime history as a daily record of how each component performed. In Convot, the public page shows a 90-day bar for each monitored component, one segment per day:

The overall percentage beside the bar comes from all checks in the last 90 days. For scale, 99.9% uptime over 90 days still allows about 2 hours 10 minutes of downtime, since 0.1% of 2,160 hours is 2.16 hours. Checking more often detects outages sooner but does not change the daily percentages much. Expect a few amber or red days in any honest history; a long run of perfect green on a page nobody updates is less believable than one with explained incidents.

How do you choose a status page tool for a Shopify app?

Choose a status page tool by what you need around it. Three common setups:

What is a Statuspage alternative for a Shopify app?

A Statuspage alternative for a Shopify app is a status page that lives inside your help desk, so monitoring, incidents, the help center and the support widget share one domain and one login. Convot includes this for each app on every plan, next to chat, a help center, changelog and roadmap; Starter is $49 a month for 1 app. Atlassian Statuspage has a free plan, then Hobby at $29 a month, and Instatus Pro is $20 a month, so a dedicated tool costs less if a status page is all you need, and fits better if you need email or SMS alerts for merchants, which Convot does not offer yet. The Statuspage comparison and Instatus comparison have the details.

Common questions about status pages for Shopify apps

Does a small Shopify app need a status page? A small app benefits from one as soon as an outage would bring in more conversations than you can answer quickly. Setting one up with monitoring takes less time than answering the first batch of duplicate questions.

Should a status page show every minor problem? Show anything merchants would notice. Small, short problems can be minor incidents; hiding them makes the page less trustworthy when merchants notice an issue that is not listed.

What should a health-check endpoint check? A health-check endpoint should confirm that the service can do its real job, for example that it can reach its database and queue, and return a success code only then. Keep it fast and free of login, and avoid checks that depend on outside services you do not control, or a third party’s bad day will show as your outage.

What about planned maintenance? Post planned maintenance in advance as a maintenance incident, with the start time, expected length and what will be unavailable, so merchants can plan around it.

Can each app have its own status page? In Convot, each app has its own status page, components and incidents, on its own public site, while your team manages them all in one place.

Running a status page, in seven steps

1. List four to six components merchants would recognise.
2. Add a health-check URL and automatic monitoring to each.
3. Turn on email alerts and add recipients, so your team hears when monitoring opens or resolves an incident.
4. Post the first update within minutes, with a time for the next one.
5. Move through investigating, identified, monitoring and resolved in plain language.
6. Link the page from your widget, help center and app.
7. Close each incident with a short summary of what changed.

See the status page, or start free while you are under $1,000 MRR, with 1 app and 3 seats.

About the author

Tarang Agarwal is the founder of Convot. Convot is built by Sidepanda, a small studio that runs several Shopify apps of its own, including Appointo, Depo and Panda Bundle, and supports all of them from one Convot inbox.