# How Hospitable catches incidents before customers do > Learn how Hospitable replaced four tools with Sentry for application-layer observability, using connected traces, metrics, and anomaly detection to triage incidents faster and give coding agents the right context. **URL:** https://sentry.io/customers/hospitable/ --- **Company:** Hospitable Hospitable is a property management software platform for short-term rentals. They operate across 125 countries and support stays for over 26 million guests per year. Over $5 billion in reservation revenue flows through their platform annually. Sam Jones leads the engineering team of 28 people, structured into pod-like groups called “supercells”. Agents now generate 97% of the team's code, and they ship more than 60 deploys and merge about 105 pull requests daily. Everyone who works on the Hospitable product uses Sentry, with the infrastructure supercell as the only exception. Hospitable has been using Sentry for error monitoring since 2017. Until recently, they were using a mix of Grafana, StatsD, and Victoria Metrics for logs, tracing, and metrics. But the split observability stack wasn’t working the way they needed it to. The problem wasn’t that they were lacking data, but that the right people couldn’t easily access it. Product managers and support teams had to troll through Grafana to get the insights they needed, following instructions on Notion pages just to query the data. Often, engineers would have to stop what they were doing to help out. When the team saw that Sentry had rolled out logs and metrics, they decided to try them out. They quickly found that their workflows were much simpler with Sentry. Instead of querying and piecing the data together manually across different systems, they were able to see error, performance, logs, and metrics data all connected by a single trace waterfall. When an issue arose, it became much easier for the product and support teams to understand what happened. “Sentry is a gamechanger when it comes to the speed of seeing all of this stuff.” In February 2026, before the Hospitable team moved to Sentry for metrics, a gradual feature rollout introduced an anomaly. But it wasn’t caught right away because no alerts fired. By day three of the rollout, when almost 100% of users had received the update, the team received a customer email reporting the defect. That’s when they realized they weren’t measuring the right things. They had exception-based alerting set up, but this incident didn’t trigger an exception. In this case, it was too much of an expected occurrence, not its absence. They had no way to set alerts for anomalies they hadn’t accounted for. Had the event thrown an alert, the team could have easily rolled back and fixed things. But instead, recovery involved sensitive, complex reconciliation work to restore the expected state. Most customers weren’t affected, but some required the team to work directly with them to reconcile discrepancies and make things right. In the end, the incident cost about three months of roadmap progress for engineering. This incident sparked the process of adopting Sentry for application metrics. With Sentry, they can now track a broader range of application activity. Upper and lower bounds, alongside anomaly detection, help them identify unexpected changes. Anomaly detection is particularly useful for cases they haven’t explicitly anticipated. “With Sentry, we can track what normal looks like across more of our application. Upper and lower bounds and anomaly detection help us spot unexpected changes earlier, while our on-call dashboard helps us quickly narrow down where the problem might be.” The team runs a fleet of agents they communicate with in Slack, with about 600 agent jobs running across their stack per day. At their deploy cadence, issue detection and triage are critical parts of that workload. Today, the team uses Sentry’s CLI to push errors, logs, spans, and metrics to their coding agents, which then diagnose issues and propose fixes. Currently, someone on the dev team reviews each PR before merging it, but they’re building toward having agents assess the risk and automatically merge low-risk PRs. According to Jones, Sentry will continue to play a part in agents that monitor production to figure out what’s going wrong and where it can be rolled back. “The hardest part of working with agents is making sure you're sending them the right stuff. With Sentry, the agent pulls from a single trace. We don’t have to worry about whether it’s getting the context it needs.” Application metrics: Previously, most alerts were exception-based. With Sentry Metrics, they spot unexpected changes in their application sooner. Trace-connected telemetry: Errors, logs, spans, and metrics all connected to a single trace provide context for both humans and coding agents to act faster. Automated debugging: Agents have access to Sentry data via the CLI and can automatically propose a fix for human review. Anomaly detection: Dynamic thresholds catch drift nobody predicted. Dashboards: Their on-call dashboard includes errors per minute, errors per project, and frontend UI slowdowns to help engineers quickly narrow down where a problem might be. --- *Source: [sentry.io/customers/hospitable/](https://sentry.io/customers/hospitable/)*