In this special Q&A session, the UptimeRobot community team sat down with Tomas Koprusak, CPO at Itrinity and the product development team to discuss the most requested features and upcoming improvements. Based on community feedback following the mobile application launch, we cover three critical topics: tiered alerting, status page enhancements, and API improvements.

Prefer to listen instead of read? You can play the full Q&A below:

If you’d rather read, the full text version of the conversation is available below.

Question 1: Tiered alerting and smarter outage thresholds

Community Question: We’ve noticed users are frustrated by how time alerts function, and there seems to be a gap in the documentation. Community members have prioritized requests for tiered alerting and smarter outage thresholds. Are there any plans for improving the granularity or functions around alert management?

What’s already available

Tomas Koprusak, CPO at itrinity: Let’s start with what’s actually implemented already. For thresholds and delayed alerts, we have functionality in place that many users may not be fully aware of.

For each monitor, customers can set the delay and repeat of notifications. Here’s how it works: imagine you have a monitor checking every 30 seconds. You can configure it so you don’t receive an alert right away, instead, you can delay it by two minutes. When the monitor goes down, the system waits two minutes, and if the monitor is still down after that period, you’ll receive the alert.

This delay can be set for all alert contacts assigned to the monitor or for any integrations you’ve configured. Using this functionality, you can essentially create tiers of alert groups. For example:

• Immediate notification via email
• 2-minute delay for a secondary contact group
• 5-minute delay for management
• 10-minute delay for broader team notification via Slack

This is already in place and working. It provides basic tiered alert functionality and lets you manage teams within UptimeRobot.

What’s coming: Team management

We have significant plans for improving this functionality. The main development in our roadmap is dedicated team functionality within UptimeRobot. You’ll be able to:

• Create formal teams within the platform
• Set specific thresholds and notifications for each team
• Configure escalation patterns that match your organizational structure

For example, developers might receive notifications immediately, while management only gets notified if a monitor is still down after an hour. This will greatly improve the current experience and allow the community to create the thresholds and alerts their teams actually need.

The technical challenge

To be transparent, implementing this isn’t straightforward. We need to ensure the system is reliable and works exactly as customers expect. We’ve been working on this since last quarter, and we’ve already made significant backend changes.

Previously, we were waiting for a number of checks before sending delayed notifications. We’ve refactored this to use timing-based delays instead, which is far more reliable. We’re still improving this system, and it will be significantly better in the near future. Once that refactoring is complete, we’ll move forward with the full teams management feature.

Question 2: Status pages – public-facing names and group visibility

Community Question: We have multiple highly-voted requests for public-facing or renamable monitor names and group-based status visibility. Users want finer control over what shows on their customer-facing status pages. This is especially important for service providers and enterprise teams. What can we expect for native support of public-friendly names or better aggregation on the UI side?

Current status page capabilities

Product Team Response: Status pages have been a major focus for us over the past few quarters, and we’ll continue improving them throughout Q4.

We’ve implemented two key features: tagging and grouping functionality. Both are tested and already in place, but they serve different purposes.

Tagging

Tagging is primarily for internal monitoring purposes. You can tag a monitor, then select specific tags to show all monitors with those tags on your status page. However, the tag itself isn’t displayed on the public status page, it’s purely an organizational tool.

Grouping

We modified this approach with groups. Grouping works similarly, but with key differences. You can:

• Create a group
• Add monitors to that group
• Add the group to your status page
• Display the group name directly on the public status page

When you use this feature, visitors see monitors organized by group name on your status page. Right now it’s fairly basic, you see the group name and the monitors associated with it.

What we’re researching: Group status display

What we’re actively researching is how to push this even further by setting statuses for entire groups on status pages.

Currently, in the dashboard, you can see a group and the status of the whole group. But this isn’t available on status pages yet. On status pages, you only see the list of individual monitors within the group.

We want to change this and display group status directly on status pages. This connects with the alerting improvements mentioned earlier. You’ll be able to set alerts for entire groups, such as:

• Receive a notification if any single monitor in the group goes down
• Or only alert when the entire group goes down
• Or trigger alerts when a certain threshold is reached (e.g., 3 out of 5 monitors down)

Development approach

We’re working on implementing this in a way that makes sense for most users. Some of our customers will receive invitations for user testing in the near future. We want to develop this feature collaboratively to ensure it actually works for real use cases and provides genuine value.

Question 3: API improvements for developers

Community Question: V3 launched and we got positive feedback, though we’re still rolling out knowledge alongside the feature. How are you addressing developer needs for stronger API reliability and feature coverage? For example, we had users trying to integrate with Go applications who had no documentation and wanted to know if certain endpoints were supported.

The V3 architecture

Product Team Response: As you mentioned, we’re on V3 now, the latest API launched earlier this year. The fundamental change with V3 is architectural.

The new API is based on the same internal API that we use for the dashboard. Our backend, frontend, and the API that communicates between them are now unified with the public API.

This means any functionality you can control through the dashboard can potentially be integrated into the public API. That’s the current state, we have this capability.

Documentation and new endpoints

We launched comprehensive new documentation for the API, covering:

• Everything from the previous API version
• All new functionality like tags (which weren’t available in previous versions)
• Clear endpoint specifications

We’re actively adding new endpoints as requested. Right now, we’re working with several enterprise partners who have specific API requirements. For each requested endpoint, we evaluate whether it makes sense for the broader community. If it does, we add it to the public API.

Terraform provider development

Beyond the REST API, we’ve recently integrated the Terraform provider, and we’re working intensively to improve it. We currently have one developer dedicated exclusively to Terraform, diving deep into:

• What the community needs from the provider
• How to improve the API to support Terraform better
• Closing gaps between capabilities

This isn’t a “launch and forget” situation, we’re actively improving the API day by day.

AI integration and model context protocol

Connected to the API work are current AI trends and Model Context Protocol (MCP) integration. We’ve done extensive testing and have already launched a read-only MCP version for UptimeRobot.

We’re currently working on:

• Edit functionality for MCP
• Enhanced read capabilities
• Using MCP feedback to inform new API endpoints

Again, this is all based on the V3 API. Requests that come from MCP usage will be translated into API documentation improvements and new endpoints we might add in the near future.

Looking forward

These three areas represent significant progress in a single year, moving from V2 to V3 with substantial improvements across alerting, status pages, and developer infrastructure. The interconnected nature of these requests shows that the community is actively using new features and thinking about how they fit together.

The product team’s approach of user testing, enterprise partnerships, and iterative improvement demonstrates a commitment to building features that solve real problems rather than just checking boxes on a feature list.

Stay tuned for more updates as these features roll out throughout Q4 and into next year. The UptimeRobot community can look forward to smarter alerting, more sophisticated status pages, and increasingly powerful developer tools.

Have questions or feedback about these upcoming features? Join the conversation in our community channels and help shape the future of UptimeRobot.

Join the conversation in our Discord, open an issue on GitHub, or submit a suggestion on our Nolt board.