Provider health

Pipedash watches the health of each provider next to its pipelines. It combines 3 sources into one health level per provider. The sources are the public status page, the controller checks of Tekton and Flux, and the connection of Pipedash to the provider. A warning appears only for problems that affect the pipelines.

Status pagesCopy Anchor Link

Pipedash reads the public status page of four providers. The read sends no credentials.

Other components and incidents on the same page do not raise a warning. If none of the watched components exist in the feed, Pipedash watches all components. Self-hosted GitHub, GitLab, Gitea, Jenkins and ArgoCD have no default page.

Pipedash reads each page every 2 minutes, and every minute while a provider that uses the page fails with a temporary error. A failed read waits 1 minute, then doubles for each failure in a row, up to 30 minutes. Providers that share a page share one read. Pipedash reads pages only while the app is in active mode. The Refresh all button reads again the pages that are older than 15 seconds.

A report is fresh for 15 minutes. Between 15 minutes and 1 hour the status view marks it "Last report may be out of date". After 1 hour Pipedash drops it.

Custom status page URLCopy Anchor Link

GitHub, GitLab, Gitea, Jenkins, ArgoCD, Tekton and Flux providers have a field named "Status page URL (optional)". It sets the status page of an own instance. For GitHub and GitLab, it replaces the default page.

• Format: an https URL with a host, without credentials, query or fragment. http works only for 127.0.0.1 and [::1].
• Feed: Pipedash reads api/v2/summary.json below the URL, in the Atlassian Statuspage format.
• Name: the page shows under the host name of the URL, and Pipedash watches all components.
• Config file: the key is status_page_url in [providers.<id>.config].

An invalid URL makes the provider fail to start. The message reads "status_page_url must be an https URL with a host and no credentials, query or fragment".

Controller checksCopy Anchor Link

Tekton and Flux providers check the controllers in the cluster. Pipedash reads the Deployments every 2 minutes with a 10 second timeout. It checks after a successful fetch and only in active mode.

A controller with no problem does not show. Pipedash reports these states:

The check needs permission to read Deployments in that namespace. Without it, Pipedash shows no controller health. Pipedash leaves out a Deployment that does not exist.

Which problems raise a warningCopy Anchor Link

Each signal has a level: Operational, Maintenance, Degraded, Partial outage or Major outage. The provider takes the highest level among its fresh signals. A warning appears at Partial outage and Major outage. Maintenance and Degraded show in the status view without a warning.

The connection of Pipedash adds signals after failed fetches:

A rejected token, missing permissions, an invalid configuration or a certificate error is not an outage. These failures mark the provider with a red "Fetch failed" badge and the hints "The token was rejected" and similar. The badge appears in the Provider column and in the sidebar.

A warning shows as an orange badge on the provider icon. The provider also joins the "Affecting pipelines now" list of the bell. Pipedash sends an alert when one of these starts:

• A status page incident at Partial outage or worse.
• A status page that reports Partial outage or worse without an incident.
• A controller at Major outage.
• A connection problem that reaches Major outage or Partial outage.

Each issue alerts once, and the same issue cannot alert again for 15 minutes. A rate limit never alerts. The recovery alert follows 2 clean checks of a status page or of controllers, or 1 clean fetch for the connection. The first check after startup is a silent baseline, so an outage that already exists raises no alert. The Notifications page covers delivery.

Provider status viewCopy Anchor Link

A click on a provider in the Provider column opens the status view. The button in the Provider column has the name View <provider> service status. The same view opens from the bell and from a notification. The title shows the provider name and its headline, or "No problems affecting your pipelines".

The view has up to 3 sections:

• Service status: the section has the title <page name> status. It shows when Pipedash checked the page, for example "Checked 2 minutes ago", and an Open status page button. Below come the watched components with their level, the incidents with a link, planned maintenance and the other incidents on the page. A provider without a page shows "No public status page. Pipedash reports connection problems."
• Controllers: the components with a problem and their detail. The section appears only when a controller has a problem.
• Pipedash connection: the state of the last fetch, such as "Working · last fetch 1 minute ago", "Last fetch failed" or "Not fetched yet". Notes follow, such as "Checking now", "Next attempt after 4:12 PM" and "Showing data from 10 minutes ago". The Retry now button refreshes the provider. A token, permission, configuration or certificate failure adds an Open provider settings button.

A failed read of the status page shows its error with the time of the last successful check. Settings, under Providers, shows a Status row for each provider. The row reads for example GitHub · Operational · checked 2 minutes ago and has an Open status page button. Upcoming maintenance appears below it.

Alert bellCopy Anchor Link

The bell in the header collects provider alerts and pipeline alerts. A dot on the bell marks unread items. The dot is orange for an outage, red for a failure and green for a recovery. The list also shows each provider that currently affects pipelines, even before an alert arrives. The Notifications page covers the list and the system notifications.

Turning status pages offCopy Anchor Link

The switch "Check provider status pages" in Settings, under General, controls the status page reads. Its description reads "Reads the public status page of each provider, or the one you configured. No credentials are sent."

• Config file: general.status_pages_enabled in config.toml. The default is true.
• Environment: PIPEDASH_STATUS_PAGES_ENABLED overrides the value. true, 1 and yes turn the reads on and any other value turns them off.
• Effect: with the switch off, Pipedash reads no status pages. The status view says "Pipedash reports connection problems." Controller checks and connection signals continue.
• Turning on again: Pipedash starts with a new baseline and reports no outage that already exists.
• iOS: the setting also goes into the Keychain copy that background checks use.

Backoff while a provider failsCopy Anchor Link

A provider that fails to answer slows down. The wait before the next fetch doubles for each failure in a row, up to 10 minutes. A rate limit can wait up to 1 hour. A major outage keeps at least 2 minutes between fetches. The Refresh page lists the rules.

The status view shows the schedule as "Next attempt after <time>". The Retry now button refreshes at once. It skips a provider that started a fetch less than 10 seconds ago. When a major outage on a status page ends, Pipedash fetches the provider at once and returns to the normal interval after a success.