Skip to content

Clarify multi-environment monitoring guidance - #454

Merged
thebiglabasky merged 3 commits into
mainfrom
herve/eng-102-environment-docs
Jul 27, 2026
Merged

Clarify multi-environment monitoring guidance#454
thebiglabasky merged 3 commits into
mainfrom
herve/eng-102-environment-docs

Conversation

@thebiglabasky

Copy link
Copy Markdown
Contributor

Summary

  • replace the abstract Environments page with a decision guide for ephemeral testing and persistent monitoring
  • document the project-per-environment model, stable project identities, CI branch mapping, per-environment variables and secrets, and environment-specific check selection
  • clarify that checkly test --env and --env-file values do not update scheduled monitors

Why

The existing guide made environments sound like a first-class Checkly resource, but did not explain how projects, variables, and CI/CD deployments fit together. Its examples also omitted required project identities and demonstrated testing staging while deploying only production, leaving the continuous multi-environment workflow unclear.

This documents the workflow that is supported today without implying additional product functionality.

Related context: ENG-102

Validation

  • checkly validate for the shared multi-environment configuration and check
  • checkly validate for environment-specific checkMatch
  • npx mint broken-links
  • frontmatter and canonical integrity check
  • legacy redirect destination check
  • sitemap regeneration produced no diff

@mintlify

mintlify Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
checkly-422f444a 🟢 Ready View Preview Jul 27, 2026, 5:03 PM

@thebiglabasky
thebiglabasky marked this pull request as ready for review July 27, 2026 17:09
Comment thread concepts/environments.mdx Outdated
| Test an ephemeral preview deployment | Run `checkly test` with temporary environment variables. Do not deploy it as a scheduled monitor. |
| Continuously monitor the same checks in development, staging, and production | Deploy the same check code as a separate CLI project for each environment. Give every project a unique, stable `logicalId`. |
| Continuously monitor different checks in each environment | Use a separate project for each environment and select shared and environment-specific check files in the project configuration. |
| Test lower environments but monitor only production | Run `checkly test` against lower environments, then deploy only the production project. |

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks a bit odd. Not sure what a "lower" environment is and what's the use case. I'd strike that out

Comment thread concepts/environments.mdx Outdated
CHECKLY_ENVIRONMENT=staging \
ENVIRONMENT_URL="https://staging-api.example.com" \
API_TOKEN="$STAGING_API_TOKEN" \
npx checkly deploy --force

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't default examples to --force

@thebiglabasky
thebiglabasky merged commit 1d6e737 into main Jul 27, 2026
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant