Portal Reporting
Use Portal Reporting when Business or Enterprise users should review run history, scenario trends, latency percentiles, and byte metrics from the customer portal.
Matching docs
Search across docs titles, summaries, groups, and section headings.
Use Up and Down Arrow to move through results, then press Enter to open the active page.
No indexed docs matched that search. Try a broader term or open the docs hub.
What this page helps you do
What this page helps you do
Use Portal Reporting when Business or Enterprise users should review run history, scenario trends, latency percentiles, and byte metrics from the customer portal.
Who this is for
Teams exporting final run data and realtime metrics into supported observability backends.
Prerequisites
- A run result or sink destination you want to wire into the wider observability stack
By the end
A sink-specific setup path that stays tied to the same LoadStrike report model.
Use this page when
Use this page when the local report is not the only destination and you need to wire realtime or final export into a supported sink.
Visual guide
Sample Report Data Rows
Scope Scenario Result Count RPS LatencyP50Ms LatencyP80Ms LatencyP85Ms LatencyP90Ms LatencyP95Ms LatencyP99Ms
Scenario reports-demo OK 675 15.0 21.4 30.2 33.0 36.8 48.6 72.1
LatencyTable Scenario Result Count LatencyP50Ms LatencyP95Ms
LatencyTable reports-demo OK 675 21.4 48.6
LatencyTable reports-demo FAIL 12 35.9 79.2
StatusCode Result Percent
200 OK 97.48
500 FAIL 2.52
FailedStatus Scope Scenario Step StatusCode Count Percent
FailedStatus Scenario reports-demo 500 12 1.75Reporting
Realtime reporting
Choose Portal Reporting when users should review runs in the customer portal, pick the built-in sink page that matches the backend your team already runs, or open Custom Reporting when you need to implement your own destination. Each tab opens a dedicated page with the settings, behavior, and lifecycle details for that reporting path.
Guide
When To Use Portal Reporting
Choose Portal Reporting when the people reviewing performance runs should not need local report files or a separate observability backend. It gives signed-in account users a shared Run Reports tab for runs produced by their own licenses.
What Users Can Review
The portal shows run summaries, scenario rows, interactive trend charts, latency percentiles, request counts, success and failure counts, failure rate, duration, and bytes. The default graph is a line chart with hover values, highlighted points, and a crosshair for comparing visible scenarios. Users can switch to other supported views when the page allows it.
Filters, Saved Views, And Sharing
Users can search timestamped run names, filter by preset or custom time range, scenario, metric, and percentile, and star up to five baseline runs so important comparison runs stay easy to pick. The scenario picker updates from the selected run so users only choose scenarios available in that run. Saved views keep useful combinations such as checkout p95 or payment scenarios last 7 days close at hand. Users can also export the visible trend as CSV, export the chart as PNG, or copy a portal link with the current filters preserved.
Repeated Runs
Each SDK execution appears as its own portal run, even when a project reuses the same SessionId for external log or trace correlation. That keeps portal history easy to compare while preserving the customer-supplied session label inside the run metadata.
Interrupted Runs
If a test host stops abruptly before it can send the final portal reporting update, LoadStrike closes the stale portal run after the associated runner session is no longer active. The run remains available in Run Reports with the most recent realtime metrics that were received.
Display Controls
Latency views support p50, p75, p95, and p99. Bytes, request counts, failure counts, failure rate, and duration can be reviewed alongside latency. Users can show or hide series, smooth lines, show or hide points, choose linear or log scale when useful, and switch between chart, table, or chart-plus-table layouts.
Comparisons And Drill-Down
Run Reports can compare the selected run with the previous run or a selected baseline. Scenario rows open a detail view with synchronized charts for latency, requests, failure rate, and bytes, plus failure and tracking summaries for the selected run.
Threshold Markers
Users can set latency, failure-rate, and request-volume targets in the filter bar. The portal marks pass or breach status in the report summary and overlays target markers on matching charts.
Account Visibility
Customer portal reports are account-scoped. A signed-in portal user can review runs linked to licenses in their own account, not reports from other accounts.
Plan Gate
Portal Reporting is available on Business and above. Use a valid Business or Enterprise runner key when enabling WithPortalReporting.
Portal reporting setup
Use WithPortalReporting when a Business or Enterprise run should appear in the customer portal Run Reports tab.
If you run these examples locally, add a valid runner key before execution starts. Set it with WithRunnerKey("...") or the config key LoadStrike:RunnerKey.
HTML reports also include the top-right Light/Dark theme toggle. Light is the default report theme.
Portal Reporting
using LoadStrike;
var scenario = LoadStrikeScenario.Empty("orders-portal-reporting")
.WithLoadSimulations(
LoadStrikeSimulation.Inject(rate: 25, interval: TimeSpan.FromSeconds(1), during: TimeSpan.FromMinutes(2))
);
LoadStrikeRunner.RegisterScenarios(scenario)
.WithReportingInterval(TimeSpan.FromSeconds(5))
.WithPortalReporting()
.WithRunnerKey("rkl_your_business_or_enterprise_runner_key")
.Run();package main
import loadstrike "loadstrike.com/sdk/go"
func main() {
scenario := loadstrike.CreateScenario("orders-portal-reporting", func(loadstrike.LoadStrikeScenarioContext) loadstrike.LoadStrikeReply {
return loadstrike.LoadStrikeResponse.Ok("200")
}).
WithLoadSimulations(loadstrike.LoadStrikeSimulation.Inject(25, loadstrike.DurationFromSeconds(1), loadstrike.DurationFromSeconds(120)))
loadstrike.RegisterScenarios(scenario).
WithReportingInterval(loadstrike.DurationFromSeconds(5)).
WithPortalReporting().
WithRunnerKey("rkl_your_business_or_enterprise_runner_key").
Run()
}import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeRunner;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeResponse;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeScenario;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeSimulation;
var scenario = LoadStrikeScenario
.create("orders-portal-reporting", ignoredContext -> LoadStrikeResponse.ok("200"))
.withLoadSimulations(LoadStrikeSimulation.inject(25, 1d, 120d));
LoadStrikeRunner.registerScenarios(scenario)
.withReportingInterval(5d)
.withPortalReporting()
.withRunnerKey("rkl_your_business_or_enterprise_runner_key")
.run();from loadstrike_sdk import LoadStrikeResponse, LoadStrikeRunner, LoadStrikeScenario, LoadStrikeSimulation
scenario = (
LoadStrikeScenario.create("orders-portal-reporting", lambda _: LoadStrikeResponse.ok("200"))
.with_load_simulations(LoadStrikeSimulation.inject(25, 1, 120))
)
LoadStrikeRunner.register_scenarios(scenario) \
.with_reporting_interval(5) \
.with_portal_reporting() \
.with_runner_key("rkl_your_business_or_enterprise_runner_key") \
.run()import {
LoadStrikeResponse,
LoadStrikeRunner,
LoadStrikeScenario,
LoadStrikeSimulation
} from "@loadstrike/loadstrike-sdk";
const scenario = LoadStrikeScenario
.create("orders-portal-reporting", async () => LoadStrikeResponse.ok("200"))
.withLoadSimulations(LoadStrikeSimulation.inject(25, 1, 120));
await LoadStrikeRunner
.registerScenarios(scenario)
.withReportingInterval(5)
.withPortalReporting()
.withRunnerKey("rkl_your_business_or_enterprise_runner_key")
.run();const {
LoadStrikeResponse,
LoadStrikeRunner,
LoadStrikeScenario,
LoadStrikeSimulation
} = require("@loadstrike/loadstrike-sdk");
(async () => {
const scenario = LoadStrikeScenario
.create("orders-portal-reporting", async () => LoadStrikeResponse.ok("200"))
.withLoadSimulations(LoadStrikeSimulation.inject(25, 1, 120));
await LoadStrikeRunner
.registerScenarios(scenario)
.withReportingInterval(5)
.withPortalReporting()
.withRunnerKey("rkl_your_business_or_enterprise_runner_key")
.run();
})();Portal reporting checklist
Enables customer portal Run Reports for this run. No separate vendor backend settings are required.
Portal Reporting is available on Business and above.
Set a reporting interval when users should see periodic updates while a run is active.
If the test host exits before the final portal update is sent, the stale run is closed after its runner session is no longer active and remains visible with the latest received realtime metrics.
The Run Reports tab lists parallel and repeated runs separately with their run timestamp, and lets users search timestamped runs and scenarios, filter by preset or custom time range, metric, percentile, and quality targets, star up to five comparison baselines, then save recurring views.
Users can compare the selected run with the previous run or a selected baseline, then drill into a scenario for synchronized latency, request, failure-rate, and byte trends.
The portal opens with a line graph by default, and users can switch to other supported graph views, density settings, and chart/table layouts from the page controls.
Users can export visible trend data as CSV, export the chart as PNG, or copy a portal link with the current filters preserved.
Users can review latency percentiles, request counts, success and failure counts, duration, and bytes.