Dependencies

Follow the third-party services you depend on and get an incident in your workspace when they go down, without adding a single monitor.

Overview

Most production incidents that are not your fault still page you: GitHub Actions stalls your deploys, Stripe rejects checkouts, a DNS provider stops resolving. Uptimy already checks the services behind upti.my/status every minute from six regions on every continent. Dependencies lets a workspace follow those checks: when one goes down, an incident opens in your workspace and your alerting workflow fires, exactly as it would for one of your own healthchecks.

Nothing is copied. The checks keep running once, in our platform workspace, and their outages are forwarded to every workspace that follows them. Following does not count against your healthcheck quota.

Following a service

There are two ways in:

From Dependencies in the app sidebar, pick a service under "Services you can follow".
From any service page on upti.my/status, use Notify me about <service>. If you are signed out you go through sign-up first and land back on the same page.

Both open the same form: choose the workspace, then tick the checks you want to be paged about. By default the checks a team is most likely to care about are selected (the API, the website, the product surfaces) and the informational ones are not (the vendor's own status feed, DNS, documentation). Every check comes with a one-line explanation of what breaks for you when it fails.

What happens on an outage

A followed check is marked Down only when it fails from every region at once; a single region failing shows as degraded on the public page and does not alert anyone. When it goes down:

An automatic incident opens in your workspace, titled after the check, for example GitHub · API Requests is down. Its source is shown as "Public service" and links back to Dependencies.
Your alerting workflows run on incident.created, so Slack, email, webhooks, PagerDuty and on-call escalation behave as they do for your own monitors.
When the check recovers, the incident resolves and incident.resolved fires.

The incident is a real incident in your workspace: it appears in the incident list and dashboard banners, it can be attached to your status pages, it is counted in reports, and a maintenance window that lists the followed check suppresses it.

💡 Also monitor your side of the dependency

A vendor outage matters because of what it breaks for your users. Add a healthcheck for the API route, webhook receiver or scheduled job that calls the vendor, so you learn about the failure that actually affects them, and follow the vendor to know whose fault it is.

Editing and unfollowing

Expand a service on the Dependencies page to see the followed checks with their live status, and use Edit checks to change the selection or Unfollow to drop the service. Unfollowing resolves any open incident about it in your workspace without sending alerts. If we remove a check from a service, its follow is dropped and any open incident is resolved the same way.

From the CLI and your AI assistant

You can do the same from the command line with uptimyctl (uptimyctl dependencies follow github), or from an AI assistant connected to the MCP server, which also sees the status of the services you follow when you ask what's down.

Plan limits

The limit is on services, not checks: follow as many of a service's checks as you like. The Free plan can follow two services; paid plans are unlimited. The limit applies when you add a service, so if you move to a smaller plan your existing follows keep working and you simply cannot add more until you are under the limit.

ℹ️ Only full outages alert

Followers are paged on Down, which requires every region to fail. Regional degradation is visible on the public status page but does not open an incident. If you need to react to partial degradation of a vendor, add your own healthcheck against the endpoint you use from the regions you serve.

Status badges and sharing

Every service page at upti.my/status serves a live status badge you can embed in a README, wiki, or runbook. It is a plain SVG in the shields.io style, updated every minute from the same probes, and it links back to the service page:

https://www.upti.my/status/<slug>/badge.svg              whole service
https://www.upti.my/status/<slug>/badge/<probe-key>.svg  one check

Probe keys are the ones the public catalog lists for the service, for example dc-fsn1 for Hetzner's Falkenstein datacenter. The Embed a live badge section on each service page previews the badge and gives you the Markdown and HTML to paste. If our API is unreachable the badge shows a grey checking rather than a broken image.

The verdict on each page also has Copy link (the native share sheet on phones) and Share on X buttons. Both carry a one-line summary of the current state, such as how many checks are failing from how many regions, and the page link, which unfurls into a card showing the live status.

Permissions

Viewing Dependencies needs workspace membership. Following, editing and unfollowing need the workflow.update permission, since they change what alerts your team.