Integrate Checkly with Render for more reliable production environments

With Render’s announcement this week of their new webhook integrations triggered by Render events, I wanted to explore how the integration between Render and Checkly can help ensure more reliable production services for your users.

Render is a cloud application platform that enables developers to deploy and scale their apps without needing to manage infrastructure. As a tool to let developers flexibly deploy their applications, Render enables a more complex, and more customized, architecture for your applications. While cloud applications have achieved amazing things in terms of scalability and efficiency, it’s no secret that our applications have also increased in complexity.

With Checkly, the simple question of ‘is this service working for all users’ is easier than ever to answer. Checkly monitors production websites and API endpoints and alerts you when something isn’t working. With the powerful Playwright automation framework, engineers can write monitors on Checkly that simulate complex user behavior, and make sophisticated assertions to make sure your application is meeting user expectations.

While it’s great to use Checkly to monitor your Render production services, with the new webhook integrations announced this week, you can go a few steps further: updating your Checkly monitors after a deployment, and running Checkly against your application pre-deployment. This article describes how these two use cases work and how they can benefit your team.

Running Checkly Monitors Post-Deployment

In the first example, you’ll run all your Checkly monitors right after a deployment, helping to make sure that everything is working as expected post-deployment. How it works:

1. Store your Checkly monitors in a code repository on GitHub, implementing our monitoring as code model.
2. Follow the documentation for the Render integration with GitHub actions via webhooks, create a webhook with the URL from your service and /webhook path that is triggered upon the DeployEnded event.
3. Add a few steps to your GitHub Action to kick off Checkly monitors.
4. Route your results back to the GitHub action report with run: cat checkly-github-report.md > $GITHUB_STEP_SUMMARY .

Here’s a repository where a GitHub action is kicking off Checkly tests, and appending the results to the GitHub summary. You could alternatively forward the step summary with a curl from within the GitHub action to another reporting endpoint.

One step further: updating golden files after a deployment

Create and update the golden files in your tests everytime there’s a new deployment, creating a new ‘standard’ for future comparison. Add the --update-snapshots flag and that’s it: npx checkly deploy --update-snapshots.

Golden files are the files that Playwright tests use to compare JSON responses or the screenshots used for visual comparison tests. Updating golden files shouldn’t be done with every production deployment automatically, since we want to make sure the new version is ‘right,’ but if you’re testing an early environment thoroughly, you may want to add this flag when doing a final deployment, for example after you’ve completed successfully a canary deployment.

Pre-deploy testing with Checkly

Playwright is an automation and testing framework, and for pre-deployment end-to-end testing it’s an awesome tool for QA teams. But there are a few reasons you might want to run the same Playwright tests through the Checkly system before deployment:

• Checkly’s multiple geographic locations make testing more reliable
• Checkly’s consistent containers supply bullet-proof consistency for each check run
• You want to view and share run results with the Checkly UI
• You’re integrating backend trace data with Checkly Traces and want to see what’s traced in the backend of your web application with each run of your Playwright tests

Here’s how you’d use Checkly to ensure that new code is working, and then kick off a Render deployment if so:

1. As above, manage your Checkly code via a monitoring as code model in a shared GitHub repository.
2. Push your code to GitHub for Render to deploy into a staging environment
3. Pass the staging environment as an environment variable for your GitHub action (or hard-code its value if you’re always using the same staging environment).
4. Now, the GitHub Action will trigger Checkly tests before deploying in that specific environment,
5. If tests don't pass, open the check result, and see what needs to improve. Push a new commit, and repeat!
6. Once your monitoring checks pass, kick off a Render deployment.

Github Action code to kick off a Render deployment

While the first part of your check run will be similar to that in our GitHub Action documentation, the final step will add a Render deployment:

      - name: Deploy
        # Only run this step if the branch is main, checks were succesful, and the GitHub environment is production
        if: github.ref == 'refs/heads/main' && steps.run-checks.outcome == 'success' && github.event.deployment_status.environment == 'Production'
        env:
          deploy_url: ${{ secrets.RENDER_DEPLOY_HOOK_URL }}
        run: |
          curl "$deploy_url"

Conclusions

After a deployment, you can run Checkly monitors to confirm your app is working correctly. You can also update "golden files" to set new standards for future tests. Before deploying, Checkly can test your app in multiple locations and consistent environments, giving you confidence that your code is ready for production.

By combining Checkly and Render, you can catch problems early, improve deployment reliability, and keep your users happy. As apps get more complex, these flows become essential for maintaining quality. Try Render's webhooks in your GitHub Actions along with Checkly today to make your deployment process smoother and more reliable.