Rolling 30-day uptime
99.95%
Status: OperationalPublic beta health page
Reliability supports better product changes
This page supports the main Hullahoop loop. Start with real user behavior, turn it into the next change, then use a rollout with health checks to validate it.
Methodology updated: February 27, 2026 at 10:30 AM UTCScope: Platform-wide metricsExample data shown below
Example health snapshot
Illustrative sample metrics. Per-project live metrics are in beta.
Median recovery time (MTTR, 30d)
4m 12s
Rollouts with rollback path prepared
100%
Largest spike absorbed (30d)
12.4x baseline traffic
Who approves what: Approval mode vs Auto
Approval mode and Auto mode exist to support rollout decisions once a change is ready. They are not the main value prop.
| Action | Mode | How it works |
|---|---|---|
| Connect a repository and grant permissions | Approval mode | You explicitly choose the repo scope in GitHub. |
| Approve Patcho recommendations | Approval mode | Patch proposals are reviewed before merge. |
| Roll out approved changes in steps | Auto | Approved changes can be validated and rolled out gradually based on risk. |
| Trigger recovery actions from production signals | Auto | Health checks, runtime telemetry, and policy rules trigger rollback or patch workflows. |
Example trigger log and recovery actions
Sample format| Date | Severity | Impact | Recovery time | Root cause | Follow-up |
|---|---|---|---|---|---|
| February 18, 2026 | P2 | Elevated latency in one region | 6 minutes | Database connection pool saturation | Added concurrency guard and pool alerting threshold |
| February 6, 2026 | P2 | Delayed change-processing queue for a subset of projects | 9 minutes | Worker contention during dependency install burst | Introduced per-queue backpressure controls |
Project health FAQ
Common questions about the systems that support behavior-led changes.
How does this support the main Hullahoop value prop?
Hullahoop starts with real user behavior and turns it into the right changes for your app. Reliability systems support that loop by helping you stage, validate, and watch each rollout after it starts.
What inputs does Patcho use to decide actions?
Patcho uses behavior signals, runtime telemetry, code and release events, and user-provided context to suggest the clearest next change.
Does Patcho always need human approval?
No. You can run in Approval mode or policy-driven Auto mode, depending on risk level and your operating preference.
Signals, methodology, and limits
Uptime: share of successful request handling over a rolling 30-day window.
Recovery time: incident detection to confirmed healthy state.
Trigger signal: user input, health-check degradation, release failure, or runtime anomaly that starts a recovery workflow.
Role in the product: these systems support rollout planning and validation after Hullahoop has surfaced a change worth making.
Current limitation: this page shows example data and platform-wide summaries during beta.
Status and support
Status updates: hullahoop.ai/reliability
General enquiries: contact@hullahoop.ai
Incident support: support@hullahoop.ai
Security disclosure: security@hullahoop.ai