Bring your own runner: Synthetic Monitoring with Blackfire Player
Blackfire’s built-in Synthetic Monitoring scheduler was convenient … until it wasn’t. We’re moving to Blackfire Player with –report, so your checks run from your own infrastructure, integrate with your CI/CD, and keep your secrets where they belong.
By Thomas di Luccio, on Apr 01, 2026 For a while, Blackfire has offered built-in Synthetic Monitoring, which lets you schedule periodic scenarios and runs directly from the Blackfire platform. We call it Blackfire Builds.
No external tooling required, just configure and go.
It worked. But it came with strings attached.
The problem with Blackfire-hosted scheduling
Scheduling from Blackfire’s side is convenient when your setup is simple. But as soon as your application grows in complexity, so does the friction.
Credentials and secret variables? You had to rely on workarounds to store them safely. Monitoring behind a firewall or a VPN? Out of luck, the runner lives on our side, not yours. A bit more configuration is required.
Want to trigger a run as part of your deployment pipeline? There is no obvious solution to programmatically fetch the granular results.
The more advanced your setup, the more the convenience evaporates.
A better way: Blackfire Player with --report
We’re introducing a new approach to Synthetic Monitoring built on Blackfire Player, our open-source CLI web crawler.
The key is a single flag: --report.
blackfire-player run monitoring.bkf \ --blackfire-env=<ENV_NAME_OR_UUID> \ --report
--report requires Blackfire Player 2026.4.0 or later.
That’s it. Run your .bkf scenario files from anywhere – your local machine, your CI runner, a cron job on your server – and Blackfire Player sends a full aggregated report to your Blackfire environment with links, performance metrics, and assertion results.
Why this changes everything
It runs on your infrastructure. Behind a firewall, on a staging server, inside a VPN, if your code can reach the app, so can the monitoring.
Your secrets stay yours. Environment variables, credentials, tokens: they live in your CI/CD pipeline or your cron environment, managed the same way as everything else. No more tricks, no more custom secret storage.
It integrates natively with CI/CD. Blackfire Player exits with meaningful codes: 64 for scenario failure, 65 for fatal error, 66 for non-fatal error. Your pipeline already knows what to do with that. Fail the build, send a notification, open an incident. Standard tooling, zero glue.
It runs exactly when you need it. Post-deployment hook, pull-request check, scheduled cron. You control the trigger. Monitoring becomes a first-class citizen in your workflow, not a parallel system you have to remember to update.
It targets any environment. Use the --endpoint flag to point your scenario at any URL. Staging, production, a feature branch preview. Same scenario file, different target.
What happens to the old way
Blackfire-hosted Synthetic Monitoring scheduling will be deprecated at the end of May 2026.
Before then, we recommend migrating your scenarios to Blackfire Player with `–report`. If you’re already writing .bkf files, the scenario format doesn’t change. You’re just moving where the runner lives.
Check the Synthetic Monitoring documentation for everything you need to get started, and upgrade Blackfire Player ( v2026.4.0 or later)
Synthetic monitoring should live where the rest of your reliability tooling lives: in your pipeline, under your control, with your secrets. That’s what this change is about.
To better observability and beyond
