How to Use Checkly for Code Review

Why Use Checkly for Code Review?

Traditional code review focuses on static analysis, but what about ensuring your changes don't break the actual user experience? Checkly transforms code review by integrating real browser and API testing directly into your development workflow. Instead of just checking syntax and logic, you can verify that login flows work, APIs respond correctly, and critical user journeys remain intact after every commit.

When you define monitoring checks as code using TypeScript and Playwright, your review process becomes comprehensive. Pull requests include both application changes and the tests that verify those changes work in production-like conditions. This approach catches integration issues, performance regressions, and user experience problems before they reach production.

Getting Started with Checkly

You'll need a Checkly account and the CLI installed locally. Checkly operates on a freemium model with generous limits for development teams.

First, install the Checkly CLI:

```bash npm install -g checkly ```

Sign up at checkly.com and create your first project. You'll receive an API key that connects your local development environment to Checkly's global monitoring infrastructure spanning 20+ locations including US East, US West, Europe, and Asia Pacific.

Initialize a new monitoring project in your application repository:

```bash checkly init ```

This creates a `__checks__` directory alongside your application code. The key insight is treating monitoring checks as first-class code artifacts subject to the same review process as your application logic.

Step-by-Step Setup

Configure Your Project Structure

Your monitoring checks should live alongside your application code. A typical structure looks like:

``` src/ components/ pages/ __checks__/ api/ browser/ checkly.config.ts package.json ```

In `checkly.config.ts`, configure your project settings:

```typescript import { defineConfig } from 'checkly'

export default defineConfig({ projectName: 'My App Monitoring', logicalId: 'my-app-monitoring', repoUrl: 'https://github.com/yourorg/your-app', checks: { locations: ['us-east-1', 'eu-west-1', 'ap-southeast-1'], tags: ['api', 'critical'], runtimeId: '2022.10', browserChecks: { frequency: 300, testMatch: '__checks__/browser/*.spec.ts' }, apiChecks: { frequency: 60, testMatch: '__checks__/api/*.spec.ts' } }, cli: { runLocation: 'eu-west-1' } }) ```

Create Browser Checks for UI Features

Browser checks use Playwright to simulate real user interactions. Create `__checks__/browser/login-flow.spec.ts`:

```typescript import { test, expect } from '@playwright/test'

test('user can complete login flow', async ({ page }) => { await page.goto(process.env.APP_URL || 'https://staging.yourapp.com') await page.click('[data-testid="login-button"]') await page.fill('[data-testid="email-input"]', 'test@example.com') await page.fill('[data-testid="password-input"]', 'password123') await page.click('[data-testid="submit-login"]') await expect(page.locator('[data-testid="dashboard"]')).toBeVisible() await expect(page).toHaveURL(/.*\/dashboard/) }) ```

For code review, this check verifies that UI changes don't break the core login experience. Reviewers can see both the component changes and the integration test in the same pull request.

Define API Monitoring Checks

API checks validate backend functionality. Create `__checks__/api/user-api.spec.ts`:

```typescript import { ApiCheck, AssertionBuilder } from 'checkly/constructs'

new ApiCheck('user-profile-api', { name: 'User Profile API', request: { method: 'GET', url: '{{API_BASE_URL}}/api/v1/user/profile', headers: { 'Authorization': 'Bearer {{API_TOKEN}}', 'Content-Type': 'application/json' } }, assertions: [ AssertionBuilder.statusCode().equals(200), AssertionBuilder.responseTime().lessThan(500), AssertionBuilder.jsonBody('$.user.email').isNotNull(), AssertionBuilder.jsonBody('$.user.status').equals('active') ] }) ```

These checks catch API breaking changes during code review. If someone modifies the user profile endpoint structure, the check fails, alerting reviewers to potential integration issues.

Environment Variable Management

Checkly supports environment variables for different deployment stages. In your repository, create `.env.example`:

```bash APP_URL=https://staging.yourapp.com API_BASE_URL=https://api.staging.yourapp.com API_TOKEN=staging_token_here DATABASE_URL=postgresql://staging_connection ```

Configure environment-specific variables in Checkly's dashboard under Project Settings > Environment Variables. Use separate variable groups for staging, production, and feature branch deployments.

Integrate with CI/CD Pipeline

Add Checkly checks to your GitHub Actions workflow in `.github/workflows/pr-checks.yml`:

```yaml name: PR Checks on: pull_request: branches: [main]

jobs: checkly-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: 18 - run: npm ci - run: npx checkly test --env-file .env.staging env: CHECKLY_API_KEY: ${{ secrets.CHECKLY_API_KEY }} CHECKLY_ACCOUNT_ID: ${{ secrets.CHECKLY_ACCOUNT_ID }} ```

This runs your monitoring checks against the staging environment for every pull request. Failed checks block the merge, ensuring broken functionality doesn't reach production.

Tips and Best Practices

Tag Your Checks Strategically: Use tags like `critical`, `feature-branch`, and `regression` to run different check suites for different review scenarios. Critical checks run on every PR, while feature-specific checks only run for relevant changes.

Optimize Check Locations: Don't run checks from all 20+ locations during code review. Use 2-3 strategic locations like `us-east-1` and `eu-west-1` for PR checks, then expand to full global coverage in production monitoring.

Handle Test Data Cleanup: Browser checks that create test data should clean up afterward. Use Playwright's `afterEach` hooks to delete test users, reset database states, or clear temporary files.

Monitor Check Performance: Checkly charges based on check runs. A browser check running every minute from 10 locations consumes 14,400 runs monthly. For code review, run checks on-demand during PR creation rather than continuously.

Environment Parity: Ensure your staging environment closely mirrors production. Different database versions, missing environment variables, or scaled-down infrastructure can cause checks to pass in review but fail in production.

Avoid Flaky Checks: Network timeouts and race conditions create unreliable checks that frustrate developers. Use explicit waits, increase timeout values for slower staging environments, and implement retry logic for transient failures.

Security Considerations: Store sensitive data like API tokens and database credentials in Checkly's encrypted environment variables, not in your repository. Rotate credentials regularly and use least-privilege access patterns.

When Checkly Isn't the Right Fit

Checkly excels at integration and E2E testing during code review, but it's not suitable for every scenario. If your application requires extensive test data setup, complex authentication flows, or long-running processes, traditional testing frameworks might be more appropriate.

Teams with limited staging environment resources might find Checkly checks too resource-intensive for every pull request. The cost can escalate quickly for large teams making frequent commits across multiple feature branches.

For applications with strict compliance requirements, running checks against external monitoring infrastructure might violate data residency or security policies. Self-hosted alternatives or internal testing frameworks might be necessary.

If your team lacks frontend expertise, maintaining Playwright-based browser checks can become challenging. The learning curve for CSS selectors, async handling, and browser automation might slow down development velocity.

Conclusion

Checkly transforms code review from a static analysis process into dynamic validation that catches real-world integration issues. By defining monitoring checks as code, you ensure that application changes include the tests needed to verify functionality across different environments and user scenarios.

The key advantage is catching problems before they reach production while maintaining development velocity. When reviewers see both code changes and their corresponding monitoring checks, they gain confidence that the changes work as intended for real users.

Success with Checkly requires treating monitoring checks as first-class code artifacts. They need the same attention to maintainability, documentation, and testing as your application logic. When done well, this approach significantly reduces production incidents and improves overall code quality.

Compare Checkly with alternatives on ServerSpotter.