💡 Feature Requests

If a user wants to see a list of all current/past updates or info notices, they would have to click on the "Incident and maintenance history" link hidden at the bottom of the page. It would be nice to have a link/button at the bottom of an incident post - something like "View all updates".

It will be great to allow updating several status pages on an incident or maintenance without going and updating one by one

We use Statuspal for our public status page. As an EU company committed to WCAG 2.2 AA, we’d like to flag a few accessibility issues we cannot address via the status page design settings. 1) “Subscribe to incidents” modal – keyboard and focus handling Issue: Focus isn’t trapped within the modal; keyboard users can tab to content behind it. There’s no reliable way to dismiss the modal via keyboard (e.g., Esc). Initial focus isn’t set when the modal opens. Why it matters (WCAG): 2.1.1 Keyboard (A), 2.1.2 No Keyboard Trap (A), 2.4.3 Focus Order (A), 4.1.2 Name, Role, Value (A). Recommendation: Move focus to the dialog on open; restore focus to the invoking control on close. Trap focus within the modal; enable Esc to close. The markup of the dialog could have a more semantic approach, dialog element, role="dialog" etc... 2) Automatic refresh every ~60 seconds (most critical) Issue: The page auto-updates, which can interrupt reading and screen-reader navigation. Why it matters (WCAG): 2.2.1 Timing Adjustable (A), 2.2.2 Pause, Stop, Hide (A). Recommendation: Provide a visible control to pause/disable or extend auto-refresh (and remember the user’s choice). Okay solutions. Avoid full-page refresh; for minor changes, update sections with polite aria-live announcements. Better solution. 3) Current status & uptime markup Issue: Complex information is presented with multiple <span> elements. Screen readers announce it as one long line and relationships aren’t clear. Why it matters (WCAG): 1.3.1 Info and Relationships (A), 1.3.2 Meaningful Sequence (A). Recommendation: Use semantic structures: either tables with <caption>, <thead>, <th scope="col"> (e.g., Product | Status | Uptime), or well-structured documents with headings, paragraphs, and lists/definition lists where appropriate. 4) “Incident & Maintenance history” table structure Issue: Date and incident link appear in the same column; column headers are missing/unclear. Why it matters (WCAG): 1.3.1 Info and Relationships (A), 2.4.6 Headings and Labels (AA). Recommendation: Separate columns (Date | Incident | Status/Resolution). Include proper headers with <th scope="col">, consider <time datetime="…"> for dates, and ensure links have descriptive text.

Allow service dependency configuration be deployed over TF and API

Hello StatusPal Team, Currently, when updating an incident’s status, the color scheme on the public status page remains the same across all incident sub-statuses. However, for other types of posts like Scheduled Maintenance or Information Notices, it is already possible to customize the color scheme to better reflect the situation. We would love to see this same flexibility applied to incident sub-statuses. For example: When moving from creating the incident to Investigating or to Monitoring, and so on, we’d like to change the color to signal to customers that services are partially restored but the incident is not fully resolved yet. This would help us visually differentiate between a service that is completely down (Investigating) and one that is running again but still under observation (Monitoring). Feature Request: Please add the option to assign customizable color schemes to incident sub-statuses (Investigating, Monitoring, etc.), similar to what is already possible for Scheduled Maintenance and Information Notices. Additionally, it would be the perfect enhancement if the text shown on the status page could also be customized per sub-status. For example, instead of the generic “There’s an ongoing incident”, when in Monitoring we could display something like “There was an incident, we are currently monitoring the situation”. This would make incident communication clearer, more transparent, and more aligned with customer expectations. Thank you for considering this enhancement!

Enable users that have signd up via SSO to sign in via the standard sign-in page.

In the context of a SPA (Single Page Application) type App, given that there is no "page refresh" during the browsing, how can we ensure that the status remains synchronized" ? Could you plan a react component to help on that ? thanks !

It'd be great to be able to search through subscribers with partial values, such as half their email

Currently, it requires to click 'resend confirmation' one by one, and we have to navigate page by page. It would be much handy to just click on 1 button to bulk resend confirmation to all users.

Just as the "incident types" can be customized, we would like to have the possibility to customize "update types". Right now there are only two update types for scheduled maintenance: update and monitoring. We would like to create further types. The same goes for major incidents.