Server

Ability to SQL tools for monitoring usage and build performance on the platform. Teams need to track build times over specific periods, and it would be highly beneficial to categorize this data by the users who initiate each build. For example ability to get the total duration of build per month, per user, per projects, per executor type, or etc and report to financial team or engineering team for development cost. Currently we relying on direct database queries poses challenges due to potential changes in the database structure. Implementing these features will help teams better manage resources, optimize workflows, and maintain accountability.

Server 2.x had a document on setting lifecycle policy and that helped to keep the s3 and storage cost low with deleting unnecessary data. However server 3.x and 4.x did not have these documentation and it would be greatly appreciated if there is a guide to set these. Also we are not sure what the object prefix is for job artifacts. It seems S3 prefix filtering also doesn't work with wildcard patterns, https://repost.aws/questions/QU0ssGaRmOQTCvPj0O0w6Cug/questions/QU0ssGaRmOQTCvPj0O0w6Cug/does-s3-filtering-allow-wildcards-for-prefixes-in-sqs-event-notifications , so we cant express say /artifacts/picard/* /artifacts/ .

This feature request is to create an API endpoint to allow CircleCI Server admins to query the API to receive a list of a followers for a project. Currently this requires REPL access.

Financial Institution: - image: our_ecr_image:latest aws_auth: aws_access_key_id: AWS_ACCESS_KEY_ID aws_secret_access_key: AWS_SECRET_ACCESS_KEY

When vm-service fails to create an instance, it would be great to know this to get ahead of incidents. It would be great if these could be tagged with docker-engine true/false.

When troubleshooting vm-service issues, it would be great to configure the timeout where it destroys the VM to easier troubleshoot any issues that are arising whether they are on the VM or the Cluster.

Server customers should be able to set retention periods (~1-2 years) so they can ensure that their databases have predictable sizes. This will also allow migrations to run much quicker and allow customers to control how much data they want to retain in their installations.

It would be helpful as a customer to have a Nomad Autoscaling check - a test that runs enough jobs that would cause nomad to spin up 5-10 instances and scale down afterwards

At the moment the metrics are very basic and don't provide a lot if insight into how CircleCI Enterprise is behaving at the user level.We would like to have the following metrics to be able to tune our installation to our user needs and build dashboards so the developer teams can monitor their workflows.- build lifecycle metrics: succeeded, failed, queued, paused, running builds count- build duration- filter by: repo name, job name and workflow name CCI-I-917

Request: Being able to obtain accurate and up to date Load Test Metrics on ALL internal services used by Enterprise Server. For new customers looking to develop a Proof of Concept, that require a deeper knowledge of build thresholds. Example of typical requests: Can CircleCI Queue 1000 jobs with a single stage for pool (1) that each sleep for 15 minutes. For existing customer, this will greatly improve support process and pipeline. Example: The output processor service its under constant strain, however we do not know the upper limits of what this service can handle. Which typically results, in support responses of "lets just increase the memory limits and hope that it works". Which is a horrible customer experience.