Dependencies

Dependencies represent the outside services your systems lean on — a payment provider like Stripe, your primary database, a third-party API, a message queue. They live at the workspace level, so the same dependency (e.g. "Primary Postgres") can be referenced from checks across every project.

Instead of getting paged separately for every check that touches a failing service, you get one dependency you can point to as the likely root cause.

The Dependencies list

Open Dependencies in the sidebar to see every dependency in the workspace. Each one shows its name, an optional category badge, a short description, and — if it has one — the live status of the check or job that monitors it.

You can switch between a List view (a sortable table) and a Grid view (a card per dependency), search by name, and filter by category.

Monitored vs. Tracked

Every dependency falls into one of two states, shown as filter tabs at the top of the list:

• Monitored — the dependency has at least one check or job actively probing its health.
• Tracked — the dependency is documented (name, category, description) but nothing is monitoring it yet.

There's nothing wrong with a Tracked dependency — it's useful just to record that your service relies on something, even before you wire up active monitoring. Filter by All, Monitored, or Tracked to focus on either group.

Categories

Dependencies can be tagged with a category so they're easier to scan at a glance:

• Database
• Cache
• API
• Queue
• Storage
• Other

Category is optional. If you tag a few dependencies, a category filter automatically appears above the list.

Creating a dependency

Adding a health monitor

A dependency on its own is just a record. To get live status and incidents, attach a health monitor — a check or job dedicated to probing that dependency. Here's how to add the first one:

1. Open the dependency's detail page.
2. Click Add monitor.
3. Choose whether to monitor it with a check or a job.

Ionhour takes you to the check or job creation form with the dependency already selected, so once you save it, it shows up as that dependency's health monitor.

Seeing which services rely on it

A dependency's detail page also lists the relying services — the checks elsewhere in your workspace that have declared this dependency as something they depend on. See Checks for how a check's own dependencies are configured.

This is the payoff: when the dependency's health monitor goes down, you don't need to dig through every affected check one by one — open the dependency and see the full blast radius, plus the recent incidents from its monitor, in one place.

Reviewing a dependency

Click into a dependency to see:

• Details — category, current status, and last ping time, plus the health URL if you added one.
• Health Monitors — the check(s) or job(s) actively probing it, each with a live status badge, duration, expected schedule, last event, and a status timeline.
• Relying Services — every check that lists this dependency as something it depends on.
• Latest Issues — recent incidents from the dependency's primary health monitor.

Editing and deleting

Click Edit on a dependency to update its name, category, description, or health URL at any time.

Deleting a dependency unbinds it from every check that relied on it — the checks and jobs themselves keep running, they just stop referencing it as a dependency.

Next Steps