# Repair times

The idea of a pipeline is based on the Andon chord, which when pulled would indicate an issue with the quality of the manufactoring procss.

When pulled, it would shut down the entirety of the factory until the problem was resolved. Only in that way would quality be taken serious, and over time it lead to significant improvements across the factory floor.

Pipelines are no different, but so often are broken pipelines ignored for a long time. This particular endpoint tells you if pipeline repair is a priority in your organization - if not, you should either stop using them as they provide negative value, or change your culture immediately.

Given an id for an integration (with type Azure or Jenkins), you can query cycle times like so:

curl -H "X-API-Key: <your token goes here>" \
https://api.accidentalquality.com/api/repair_times/<integration_id>

fetch('https://api.accidentalquality.com/api/repair_times/<integration_id>', {
  method: "GET",
  headers: {"Content-type": "application/json;charset=UTF-8", "X-API-Key": "<your-token-goes-here>"}
})
.then(response => response.json()) 
.then(json => console.log(json)) 
.catch(err => console.log(err));

The data returned is in json format and structured as follows:

• unit (string) - Unit of the data displayed in the data array
• data (array)
  • x string - Date for the datapoint in format yyyy-mm-dd
  • y integer - Value for the datapoint in seconds

Example:

    {
        "unit":"Date/seconds",
        "data": [
            {
                "x": "1990-01-01",
                "y": 123
            },
            {
                "x": "1990-01-01",
                "y": 321
            },
            ...
        ]
    }

Note that the structure of data is the same as for cycle times and failure times so you can reuse code between these three.