Is Upscope down?

A quick note to let you know we’re transitioning to new monitoring endpoints for our status page. This change will reduce noise from false incidents and provide a more accurate picture of our service status. Previously: We reported downtime for any canary issues across most services, including when canary servers went down. This happened fairly often due to limited scaling, Kubernetes pod swaps, or during deploys. (Canary servers only handle a tiny fraction of traffic to validate new versions before rollout, ensuring we can safely roll back if needed). We also reported downtime when servers in co-browsing regions were overwhelmed with connections. This sometimes occurred at peak times (e.g. 9 a.m. in certain time zones if pre-scaling predictions were off). In reality, co-browsing wasn’t affected: only low-priority connections were rate-limited, search performance slightly degraded, or background jobs like recordings slowed down. Now: Canary monitoring will only trigger internal alerts. You’ll only see downtime reported if it actually affects usage. Overload monitoring is now handled exclusively by our DevOps team, since it does not impact client usage. We hope these updates make the status page more meaningful by cutting unnecessary noise and focusing only on issues that impact you. If you’d like to discuss these changes, feel free to reach out at [email protected]

A quick note to let you know we’re transitioning to new monitoring endpoints for our status page. This change will reduce noise from false incidents and provide a more accurate picture of our service status. Previously: - We reported downtime for any canary issues across most services, including when canary servers went down. This happened fairly often due to limited scaling, Kubernetes pod swaps, or during deploys. (Canary servers only handle a tiny fraction of traffic to validate new versions before rollout, ensuring we can safely roll back if needed). - We also reported downtime when servers in co-browsing regions were overwhelmed with connections. This sometimes occurred at peak times (e.g. 9 a.m. in certain time zones if pre-scaling predictions were off). In reality, co-browsing wasn’t affected: only low-priority connections were rate-limited, search performance slightly degraded, or background jobs like recordings slowed down. Now: - Canary monitoring will only trigger internal alerts. You’ll only see downtime reported if it actually affects usage. - Overload monitoring is now handled exclusively by our DevOps team, since it does not impact client usage. We hope these updates make the status page more meaningful by cutting unnecessary noise and focusing only on issues that impact you. If you’d like to discuss these changes, feel free to reach out at [email protected]