---
title: "Report the web apps that keep going wrong"
method: GET
path: "/WebApp/flapping_apps"
tags: ["WebApp", "Web Apps"]
---

# Report the web apps that keep going wrong

`GET /WebApp/flapping_apps`

## Request

- Base URL: `https://whm-server.tld:2087/json-api`
- URL: `https://whm-server.tld:2087/json-api/WebApp/flapping_apps`
- Auth: HTTP basic

This function reports the web applications the scheduled health
check has had the most trouble with, worst first, with a breakdown
of what was wrong each time.

An account whose applications could not be read is named in
`metadata.output.warnings` and left out, rather than failing the
whole report: a partial answer that says so is more use than none.

## Query parameters

- `days` integer
- `limit` integer

## Response `200`

HTTP Request was successful.

- object
  - `data` object
    - `apps` object[]: The applications the health check has had the most trouble with, worst first. Ranked by `restarts_recommended`, then by `incidents`, then by account and application name, so the order is stable between calls. Empty when nothing is flapping, which is the ordinary answer on a healthy server.
      - `app` string: The application's name (slug).
      - `causes` object: How many incidents there were of each cause. Ten out-of-memory kills and ten unresolvable domains are the same count and a different problem, which is what this breakdown is for.
      - `domain` string: The domain the application is bound to.
      - `incidents` integer: How many incidents were recorded for this application in the window.
      - `last_cause` string: What was wrong the most recent time.
      - `last_seen` string, date-time: When the most recent incident was recorded, in ISO 8601 format.
      - `restarts_recommended` integer: How many of those incidents the health check classified as wanting a restart, which is what "flapping" means: the same application asking to be repaired over and over. A domain that does not resolve is a fault no restart would fix, and is not counted. A count of recommendations, not of restarts made: an incident is recorded before anything acts on it, and automatic recovery is off unless an administrator turns it on.
      - `truncated` 0 | 1: Whether this application has filled its incident history, so `incidents` is a floor rather than a total. Each application keeps a bounded history, so without this flag a badly flapping application would be indistinguishable from one that flapped exactly that many times.
    - `days` integer: The window the report covers, in days.
  - `metadata` object
    - `command` string: The method name called.
    - `namespace` string: The namespace used in the API call.
    - `output` object: Additional output from the API call.
      - `warnings` string[]: The accounts whose web applications could not be read, and why. Present only when there were any. Such an account is left out of `apps` rather than failing the whole report.
    - `reason` string: The reason the API function failed when the `metadata.result` field is `0`. This field may display a success message when a function succeeds.
    - `result` 0 | 1: * `1` - Success. * `0` - Failed. Check the `reason` field for more details.
    - `version` integer: The version of the API function.

## Changes

- **2026-11-04** `6ca2c65397e3`: 1 info
  - endpoint added

[Operation history](https://skmtc.dev/cpanel/apis/whm-api/changes/WebApp/flapping_apps/get.md)

---

[API](https://skmtc.dev/cpanel/apis/whm-api.md) - [All operations](https://skmtc.dev/cpanel/apis/whm-api/llms.txt) - [OpenAPI document](https://skmtc.dev/cpanel/apis/whm-api/revisions/6ca2c65397e3?raw)