---
name: clinic-activity-hub
description: |
  Clinic Activity Hub lifecycle events through clinic-cli.
---

# Activity Hub events

Use the parent CLI command:

```text
python3 .opencode/skills/builtin/clinic-cli/scripts/clinic_cli.py activity-events --help
```

Typical use:

```text
python3 .opencode/skills/builtin/clinic-cli/scripts/clinic_cli.py activity-events \
  --cluster-id <cluster_id> \
  --start <start_unix> \
  --end <end_unix> \
  --limit 100
```

For point-in-time topology questions, prefer the higher-level snapshot command:

```text
python3 .opencode/skills/builtin/clinic-cli/scripts/clinic_cli.py topology-snapshot \
  --cluster-id <cluster_id> \
  --at <timestamp>
```

It uses Activity Hub as change evidence and avoids confusing current topology
with historical topology.

## Common event categories

| Category | Examples |
| --- | --- |
| Cluster lifecycle | create, pause, resume, restore, import |
| Scaling | modify size, scale component, capacity update |
| Maintenance | maintenance task, upgrade, patch |
| Backup / restore | backup start / finish, restore from backup |
| CDC | create, pause, resume, delete, edit, scale, failed changefeed |
| GitOps | upgrade, config-change, patch, scale, pause, resume, restore, import, backup |

## Query rules

- Use the incident window plus reasonable padding.
- Use `--name` only when the event type is already known.
- Use `--severity` to reduce noise when searching for impactful events.
- If cluster metadata already includes internal `orgID`, pass it with `--org-id`; otherwise let the CLI resolve it.
- For Premium clusters, still pass the user-facing cluster id the user asked
  about. Do not manually replace it with the parent/resource-pool id. The
  `activity-events` command first queries the requested cluster target and, when
  Clinic reports an error for a Premium child target, automatically retries the
  Activity Hub query against the parent target from cluster metadata.
- For ad-hoc Activity Hub questions, always run this builtin command instead of
  calling the Activity Hub REST endpoint directly. The direct REST path does not
  provide the Premium parent-target fallback or persisted Investibook evidence.

## Interpretation notes

- Activity events are usually supporting evidence for causality or change correlation.
- For historical topology / CPU core questions, Activity Hub should be checked
  for scale, resize, capacity, and component-change events around the requested
  timestamp. Do not claim current metadata is historical unless Activity and
  metrics support that conclusion.
- A scale, upgrade, backup, or changefeed event near the incident window should be correlated with metrics and logs before calling it root cause.
- When Premium fallback is used, the evidence contains both
  `requested_cluster_id` and `target_cluster_id`. Interpret returned parent
  target events only when the event summary, target metadata, or timing matches
  the requested cluster.