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. upti.my 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.

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.

Permissions

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