Recent changes to ServiceAlert monitoring, incident response, integrations, and public status pages.
We send an email when a meaningful product update ships.
Create badges for GitHub components as well as providers. The improved generator includes service search, platform instructions, accessible copy controls, and light or dark cards showing the source and last check time. Badge wording preserves source coverage, and the installation guide explains caching and refresh behavior.
Create a status badge →GitHub Actions, Copilot, Pages, Packages and Codespaces now have individual status pages with scoped provider notices and alert links. Three new guides help investigate Actions queues, Azure DevOps agent waits and Cloudflare gateway errors.
Check GitHub Actions →The browser extension checks a matched service when you open it, labels the evidence source and shows its check time. Status requests send the public catalog domain instead of a tenant hostname. The revised privacy disclosure explains request metadata and local storage. A manual package is available; a public store link is not available yet.
Read installation and privacy details →Three new monitor types check common blocklists, crawl a page for broken links and mixed content, and record scheduled Lighthouse results. They use the same alerting and incident history as other ServiceAlert monitors.
Create a monitor →A public status page can now show the current status of selected third-party providers. Provider issues appear as context and do not change the status of your own components.
Edit a status page →The Slack integration can collect monitor evidence, recent deployments, and related incidents in one investigation thread. A person reviews the findings before they are promoted to an incident update.
Open incident management →Install a monitoring agent in a cloud region, data center, or private network. Monitors can require any, a majority, or all selected regions to fail before an alert is sent.
View monitoring agents →Teams can create rotation schedules, publish an iCal feed, request shift coverage, and use the active on-call responder when assigning an incident commander.
Set up on-call →Public status pages can use a verified customer domain. The setup checks domain ownership, guides the required DNS change, and provisions TLS for the status-page hostname.
Configure a custom domain →Transaction monitors can run browser steps for sign-in, checkout, and other JavaScript flows. Each run records the first failed step and its timing.
Configure a transaction monitor →Web Analytics now separates connection stages and groups results by country, connection type, and CDN point of presence when that information is available.
Open Web Analytics →Monitors can be grouped under a named service such as Checkout, Authentication, or API. Incidents, on-call schedules, and status-page components can use the same service grouping.
Open services →HTTP monitors now support mTLS, OAuth client credentials, and JSON assertions. An existing monitor can also be cloned and retargeted.
Open monitors →Monitor, team, service, and MCP guides are available without signing in. The REST API reference is public as well.
Read the help center →Teams can declare an incident, assign responders, post timeline updates, publish selected updates to a status page, and coordinate through a Slack incident channel.
Open incident management →ServiceAlert alerts and recoveries can open, update, and resolve incidents in an existing PagerDuty or Opsgenie workflow.
Configure integrations →The public WHOIS tool now uses RDAP when a registry no longer provides a traditional WHOIS service.
Open WHOIS lookup →