💡 Feature Requests

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.

I add a UUID on the description of my service. And I would like this UUID appears in my alert by default. For example I could have a tick box as "Notify subscriber" to allow me to display the description or not to my alert.

Display real application latency on our status pages. In the Datadog ecosystem, this data is collected via normal application metrics, not through synthetic tests. The difference is critical for us. Synthetic tests measure your system's baseline performance from a controlled environment, while APM metrics reflects the actual performance our customers are experiencing across a wide variety of networks, devices, and geographic locations. For the sake of transparency with our clients, displaying this real-world data is important for us. So we would like to see support for setting up metric queries for StatusPal metrics like p90:trace.servlet.request{env:prod,region:eu-west-1,service:ml-internal-api}

After a short time, the list of maintenance work and incidents can be quite long. Searching for a specific incident/maintenance currently means scrolling up and down a list over several pages. Furthermore, the only visual distinction between a maintenance and an incident is the date, which is shown in the case of a maintenance. Please add two things to the incident & maintenance history: 1. Display incident history and maintenance history separately. 2. Add a search box, which allows you to search for text (Title of the incident) and/or the date.

Just as we can deactivate the notifications on start and on end of a maintenance window, we would like to deactivate the automatic updates "Started" and "Resolved" in the status page. We would rather inform manually about the start/end of a maintenance, since there can be small variations in time to the scheduled start and end time.

Hi, Rather than reusing an occurance, i would prefer to be able to configure Recurring tasks from a template. Now we have to edit a historical occurance in order to reflect in future ones.

Hello, StatusPal team! I would like to have the following for the /incidents page: About the Incident & maintenance history tab, I want to be able to display incident history and maintenance history separately And I would like to be able to display the content of these incidents or maintenance items by service (this could be implemented with tabs or by creating filtering options) Also, for Incident and maintenance information, it would be helpful if the status was easier to understand - whether it's ongoing or resolved Thank you!

Rootly is a popular replacement for PagerDuty and it would be really helpful to have an ability to update StatusPal status dashboard based on the status of service in Rootly. Rootly has webhooks system that is easy to plug and is configured on entire Rootly account level. It provides information about created, updated and closed incidents.