Dependencies

Dependencies model the external services your application relies on — databases, caches, third-party APIs, message queues. When a dependency goes down, IonHour can automatically flag all dependent services as degraded and create separate incidents for dependency impact.

Enabling Dependency Tracking

Dependency impact propagation is a workspace-level feature. To enable it:

1. Go to Settings > Workspace.
2. Toggle Dependency Impact Alerts on.

When disabled, the dependencyImpacted flag on checks is always false, and no dependency incidents are created. When enabled, IonHour evaluates dependency health on every signal.

Creating a Dependency

1. Navigate to Dependencies in the sidebar.
2. Click Create Dependency.
3. Enter a name (e.g., "PostgreSQL", "Redis", "Stripe API") and optional description.

Dependencies are workspace-scoped — they're shared across all projects in the workspace.

Linking Dependencies to Checks

There are two ways to connect dependencies to your monitoring: check-based and attribute-based.

Check-Based Dependencies

With check-based dependencies, you create a dedicated check that monitors the dependency itself, then link other checks to it.

Example: You have a PostgreSQL database that multiple services depend on.

1. Create a check that monitors PostgreSQL health (e.g., a heartbeat ping from a health check script that queries the database).
2. Create a dependency called "PostgreSQL".
3. Link the PostgreSQL check to the dependency.
4. On each service check, add "PostgreSQL" as a dependency.

When the PostgreSQL check goes DOWN or LATE, IonHour automatically marks all dependent service checks as degraded.

Attribute-Based Dependencies

With attribute-based dependencies, your services report their own dependency status in the ping payload. No dedicated dependency check is needed.

When sending a heartbeat ping, include a dependencies array in the POST body:

curl -X POST https://app.failsignal.com/api/signals/ping/YOUR_TOKEN \
  -H "Content-Type: application/json" \
  -d '{
    "dependencies": [
      { "name": "PostgreSQL", "status": "ok" },
      { "name": "Redis", "status": "down" }
    ]
  }'

IonHour matches dependency names (case-insensitive) against your declared dependencies and creates incidents for any that report as down.

Which Approach to Use

Approach	Best for	Trade-offs
Check-based	Infrastructure you can independently monitor (databases, caches)	Requires a dedicated check per dependency; provides independent health tracking
Attribute-based	Third-party APIs or services where the caller knows the status	No extra check needed; relies on the service to report accurately

If both are configured, attribute-based takes precedence when a payload includes dependencies. Otherwise, check-based evaluation runs.

How Impact Propagation Works

When a signal arrives for a service check, IonHour evaluates its dependencies:

1. Check dependencies: Query all linked dependency checks. If any are DOWN or LATE, the dependency is considered down.
2. Payload dependencies: If the signal payload includes a dependencies array, use those statuses instead.
3. Create incidents: For each down dependency, create a DEPENDENCY_DOWN incident (severity: WARNING).
4. Resolve incidents: For dependencies that recovered, resolve their incidents.
5. Update flag: Set the check's dependencyImpacted flag based on whether any dependency is down.

Display Status with Dependencies

The dependencyImpacted flag affects how a check's status is displayed:

Internal Status	Dependency Impacted	Display Status
OK	No	OK
OK	Yes	Degraded
LATE	No	OK
LATE	Yes	Degraded
DOWN	Either	Failed

A check that is DOWN always shows as Failed, regardless of dependency impact. But a check that is technically OK or LATE will show as Degraded if one of its dependencies is down — signaling that the service may not be fully healthy even if the check itself is passing.

Dependency Incidents

When a dependency is detected as down, IonHour creates a separate incident:

• Reason: DEPENDENCY_DOWN
• Severity: WARNING (not CRITICAL — the service itself may still be running)
• Title: "Service {service name} is impacted by {dependency name}"

These incidents appear alongside regular service incidents but are distinguished by their reason and lower severity. They're resolved automatically when the dependency recovers.

Dependency incidents are deduplicated — IonHour won't create multiple active incidents for the same dependency on the same check.

Deleting a Dependency

When you delete a dependency:

• All links to checks are removed.
• All active DEPENDENCY_DOWN incidents for that dependency are resolved.
• Affected service checks are re-evaluated for dependency impact.
• The dependency checks themselves are not deleted — they continue to run independently.

Best Practices

• Start with check-based dependencies for critical infrastructure. A dedicated health check gives you independent monitoring and historical data for the dependency itself.
• Use attribute-based dependencies for third-party APIs where you can't run a separate health check. Let your service report what it knows.
• Name dependencies consistently. Attribute-based matching is case-insensitive, but consistent naming prevents confusion (e.g., always use "PostgreSQL", not sometimes "postgres" and sometimes "pg").
• Don't over-declare dependencies. Only add dependencies that meaningfully affect your service. If a dependency being down doesn't impact your service's core functionality, it's noise.
• Watch for cascading alerts. If Service A depends on DB, and Service B also depends on DB, a DB outage creates dependency incidents for both. This is correct behavior — but make sure your team understands the pattern so they don't treat them as separate issues.