Server

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.

Along with metrics, it would be good to have a way to configure OTLP traces so that teams can verify API calls, etc.

Overview We're requesting a comprehensive Licensing Insights Dashboard to provide detailed analytics on user activity, track deactivation reasons, and allow permanent exceptions for critical users. Key Requirements: Dashboard Visualization Centralized overview of CircleCI licensing usage Visual charts and graphs showing active/inactive user trends Customizable time period selection User Activity Metrics: Detailed analytics on builds triggered and pipelines executed Usage metrics with filtering by timeframe (daily/weekly/monthly) Activity threshold indicators User Status Tracking: Complete user listing with current status (active/inactive) Detailed deactivation reasons with timestamps Admin accountability for deactivation actions Historical status change logs for auditing Critical User Protection: Ability to designate users as "critical" to prevent automatic deactivation Management interface for critical user list maintenance Confirmation prompts and notifications when critical users are modified Reporting Capabilities: Exportable reports on licensing usage and status changes Real-time data integration with existing CircleCI APIs Scheduled report delivery options Business Objectives: Increase transparency into license utilization Optimize resource allocation by identifying inactive users Maintain security compliance through detailed audit trails Prevent workflow disruptions by protecting essential users This feature will significantly enhance our license management capabilities while ensuring business-critical operations remain uninterrupted.

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 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