Feature request: support `--environment` flag (or config field) to differentiate monitors across deployments

[TomonoriSoejima]

Summary

When pushing the same synthetics project to multiple Kibana deployments (e.g. staging and production), the generated monitor ID is identical across deployments because it is derived solely from:

{journeyName}-{hash}-{projectId}-{space}

There is no way to include an environment identifier in the monitor ID. As a result, monitors in both deployments are indistinguishable by ID or metadata — even though they are managed independently.

Steps to reproduce

1. Create a project with a journey named my-monitor
2. Push to a staging Kibana: NODE_ENV=staging npx @elastic/synthetics push --auth <staging-key> --yes
3. Push to a production Kibana: NODE_ENV=production npx @elastic/synthetics push --auth <prod-key> --yes
4. Query monitors in both deployments:

GET /api/synthetics/project/{projectId}/monitors

Result: Both deployments return the same journey_id and identical hash:

{ "journey_id": "my-monitor", "hash": "DU6qHIltvFPOBnbXQKl6BHiUwFZIZpg9K45l6UMO9YY=" }

Expected: Some mechanism to include an environment tag or identifier so monitors can be differentiated across deployments.

Current workaround

Embed the environment manually in the journey name:

const env = process.env.NODE_ENV || "staging";

journey(`my-monitor-${env}`, async ({ page }) => { ... });

This works but is manual, not documented, and error-prone.

Proposed solution

Add an --environment flag to the push command (and a corresponding environment field in synthetics.config.ts) that is factored into the monitor ID and/or stored as monitor metadata:

npx @elastic/synthetics push --auth <key> --environment staging --yes
npx @elastic/synthetics push --auth <key> --environment production --yes

Or via config:

project: {
  id: "my-project",
  url: process.env.KIBANA_URL,
  space: "default",
  environment: process.env.NODE_ENV, // new field
}

Context

• Confirmed on @elastic/synthetics v1.23.1, Kibana 8.19.7
• No existing issue found for this
• The user had to manually add env suffix to journey names to avoid monitor ID collision across two Kibana deployments)