-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
Component/s: Components - Uptime
-
None
-
1
-
Severity 3 - Minor
Issue Summary
Public Statuspage instances with a very large number of components intermittently render only a subset of the components on the public page. During these partial-load states, the “Subscribe to updates” control on the page may also fail to open the subscription dialog and instead just refresh the page.
Steps to Reproduce
- Configure a public Statuspage with a very large number of components, close to the upper supported limit, with a significant portion of them enabled for uptime/visibility on the public page.
- As an end user, open the public URL of the page.
- Scroll through the Components section and observe how many components are displayed.
- Refresh the page multiple times.
- While the component list is only partially displayed, attempt to use the “Subscribe to updates” control.
Expected Results
- The full list of configured components (within documented limits) should render on every page load.
- The “Subscribe to updates” control should consistently open the subscription dialog (email/SMS/etc.) on every page load.
- Page rendering should not be affected by the total number of components, provided it is within supported limits.
Actual Results
- When the page has a very large number of components, some page loads only render a partial component list; the list stops at a seemingly arbitrary point even though more components are configured.
- On other loads, the full component list appears as expected.
- While the page is in this partial state:
- Only part of the components are visible to end users.
- The “Subscribe to updates” control appears on the page but, when clicked, may simply refresh the page instead of opening the subscription dialog.
- Refreshing the page multiple times can eventually result in a load where:
- All components are shown.
- The “Subscribe to updates” control works as expected.
Workaround
- Reduce the number of components that need to be fully rendered and have uptime calculated on the public page. For example:
- Use configuration options (such as “only show if degraded” or equivalent) so that certain operational components are only displayed when they are not in an operational state.
- Where possible, consolidate or simplify the component structure to reduce the total number of publicly rendered components.
These measures reduce the amount of data the page needs to process and can make it more likely that the component list will render fully and that the “Subscribe to updates” control will behave correctly.
A permanent fix is still required so that pages with large numbers of components render reliably without relying on such mitigations.