Operations | Monitoring | ITSM | DevOps | Cloud

We shipped a small improvement to monitor filtering to make it easier to stay organized — especially if you’re managing a board with a lot of monitors.

On February 10, 2026, Amazon Web Services (AWS) experienced an outage that triggered widespread reports of CloudFront failures and DNS resolution issues. While AWS later acknowledged the incident, StatusGator detected the disruption earlier using Early Warning Signals, giving customers valuable lead time before the provider confirmed anything publicly.

On February 10, 2026, Claude users around the world began reporting service failures affecting chat sessions, API integrations, and Claude Code workflows. The first verified outage report reached StatusGator at 19:33 UTC. StatusGator issued an Early Warning Signal at 20:24 UTC. Claude did not post an official “Investigating” update until 22:11 UTC. This incident clearly demonstrates the gap between real user impact and official status page updates.

StatusGator monitors services and their individual components, so you can stay informed about the systems you rely on – and filter down to only the components you care about. Most status pages do a good job of tagging incidents to the affected components. But sometimes providers publish incident updates without marking any components as impacted, even when the incident clearly affects something real.

January brought a packed set of updates to StatusGator – from better ways to organize and analyze your monitors, to new API capabilities and expanded security controls. Here’s a quick recap of everything that rolled out.

January 2026 saw a wave of high-impact service disruptions across social platforms, telecom providers, developer tools, education services, and streaming apps. In several cases, StatusGator detected problems minutes or even hours before providers publicly acknowledged them, and in many cases, providers never acknowledged them at all. Unfortunately, many providers still do not have public status pages, leaving users with little visibility into what is happening during an outage.

We’re excited to roll out an improvement many of you have been asking for: extended historical metrics for website and ping monitors. Until now, monitor metrics like availability, downtime, and response times were limited to the last 24 hours. While useful for short-term checks, this made it harder to spot trends, investigate intermittent issues, or understand long-term performance. That changes today.

We recently launched monitor groups, making it easier to organize monitors on your boards and status pages. Now that same functionality is available in the StatusGator API, so you can manage monitor groups programmatically. The API now supports listing, creating, updating, and deleting monitor groups on a board. You can also assign or remove monitors from groups when creating or updating a monitor.

We’ve added a new enhancement to the StatusGator API that makes it faster and easier to identify service issues in real time: status-based filtering for monitors and components.

This is one of our most requested features – and it’s finally here. Many of you told us that as your monitoring setup grows, it becomes harder to manage long lists of services and harder for users to quickly understand what’s actually affected during an incident. Monitor groups were built to solve exactly that. Now you can organize related monitors together and present a clearer, more structured view of system health everywhere StatusGator is used.