Performance regressions ship on a Friday
Most performance problems are not discovered, they are reported, usually by a customer and usually at the worst time. The gap is not tooling, it is placement: the test lives outside the release process, so it runs after the decision it was supposed to inform. Moving it into the pipeline changes what it is for.
LoadFocus for DevOps: FAQ
Can I run a load test from CI?
Yes. Tests can be triggered as a build step and gated on a threshold, so a build fails when performance regresses rather than after release.
What is monitoring as code?
Monitor definitions kept in version control rather than clicked into a dashboard. They get reviewed like any other change, travel with the service they watch, and can be recreated from the repository.
Which alert channels are supported?
Email, Slack, PagerDuty, Opsgenie, Microsoft Teams, Discord and generic webhooks. A channel is shared across your team and attached per check.
How do I stop flaky checks from paging on-call?
Configure retries and an alert threshold so a check has to fail more than once before it alerts, and schedule maintenance windows around planned work.
Can I monitor things that are not HTTP?
Yes. TCP monitors check that a port accepts connections, DNS monitors confirm records resolve to the values you expect, and heartbeat monitors catch a scheduled job that did not run.
Does a failed check tell me why it failed?
Browser checks capture screenshots, console logs, network logs, per-step timings and a replayable trace, so the failure comes with evidence rather than just a status.
