Audience-specific page question

[Michael Monteiga]

Hypothetically, Product ABC is a SaaS solution.  Each ABC customer's backend is individually hosted in AWS or Azure. ABC has grown tremendously and need a status page solution but does not want to have ABC customers knowing the status of other ABC customer's environments.  The issue is this: ABC now has 200 customers and expects to eventually have thousands!  

What is the recommended solution for this type of scenario? 

Thank you in advance!

[Darryl Lee]

Hi @Michael Monteiga ,

This is Darryl. I am here to help.

From your description, it looks like you will need to have separated Audience Specific pages for individual ABC's customers to subscribe to without having access to any other customers. This plan is also scalable when the customer amount increases.

Here are some documents for your further reference:

Audience Specific page pricing and the details of the Audience Specific Page pricing

introduction of Audience Specific Page

What are Audience Specific Pages

Audience Specific Page Example

For more details, please feel free to contact Statuspage Support and my colleague will help you from there.

Hope this helps.

Kind regards,
Darryl Lee
Support Engineer, Atlassian

[Majken Longlade]

To be sure - the recommendation here is a page per client? Rather than increasing the number of groups?

[Darryl Lee]

Hi @Majken Longlade, yes, because the requirement here is company ABC doesn't expect each of the clients to know the status of each other's environment, so company ABC will need to subscribe and create individual Audience Specific Page for each of the clients.

[Majken Longlade]

Thanks for confirming, maybe I'm misunderstanding how groups work? I had assumed that you'd be able to use components and groups to have multiple clients on one page, but segregate what they can see.

Though it's my understanding that there's a hard limit on components, so at some point you'd have to use multiple pages anyway?

[Zeeshan]

Hey @Majken Longlade ,

Yes Groups can be used to set what set of users are able to see what components but when you have such a large number of clients it is better to have a page per client as it is then more manageable and scaleable and that is what most of our customers go with. Then once you have a page per client, you can use the groups on a page to further categorize a client's users.

Furthermore, having separate pages will also only easier user management via SAML ass some clients may want SSO and some may not.

As for components on a page, yes there is a limit of 1100 components per page, so at some point you will have to use multiple pages anyway.

[Majken Longlade]

Thanks! 

I don't suppose there is someone already using Statuspage like this that we could be connected with to discuss how it works for them and see if we think it would work in our case?

[Zeeshan]

Hey @Majken Longlade ,

We can't be sharing any customer information of course but feel free to post in the community forums and see if any other customer who has implemented this reaches out.