Portal Reporting
Use Portal Reporting when 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 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, request counts, failure rate, p50/p75/p95/p99 latency, 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.
Cumulative Run Percentiles
While a raw-observation run is active, its detail view can show a cumulative preview from the final load-phase outcomes received so far. Once every distributed result owner has completed, LoadStrike recalculates the scenario from all deduplicated final outcomes and writes one exact history point for that scenario and run. That prevents reporting batches from appearing as separate trend runs. Success and failure detail remains available separately for diagnosis, and long cross-run series are reduced deterministically for display without averaging percentile values or hiding their endpoints.
Reliable Bounded Delivery
SDKs send individual attempts in bounded batches with stable identities. Every reporting-sink callback uses one initial attempt plus three retries by default, with delays of 250 ms, 500 ms, and 1 second. Recovered callbacks add no final sink error or warning. Only exhausted raw-observation delivery counts as dropped observations; other exhausted callbacks are reported against that sink, and exception details remain in sanitized local logs rather than portable reports. Active heartbeats renew run authorization automatically during long tests, and subsequent reporting plus best-effort shutdown use the renewed authorization. Repeated or overlapping delivery of the same unchanged report update produces one portal history point; reusing an update identity for different content is rejected. Oversized request envelopes are split, and short portal backpressure is returned with retry guidance instead of being allowed to create an unbounded reporting backlog. If any expected distributed result owner does not complete, the run remains visibly reporting-incomplete rather than publishing partial results as final.
Query Explorer, Saved Views, And Sharing
Users can enter query fields such as focus, run, metric, percentile, scenario, range, and chart, then filter by 1D, 1W, 15D, 30D, or a custom time range. Preset ranges apply automatically, while From and To are used only when Custom is selected. Scenario and run selectors list the signed-in account's available report inventory, and the selected range controls the metric window that is plotted. Scenario mode supports one or more global scenario names for that account. Run mode uses the selected run to pick its scenario set, then plots those scenarios across the selected period. 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, and failure rate 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.
Scenario-First Graphs
Run Reports opens in scenario mode. Users can select one or more scenarios to plot requests, failure rate, p50/p75/p95/p99 latency, or bytes across the selected period. If they switch to run mode, the selected run is used as a scenario set so the graph still shows scenario history rather than a run-vs-run comparison. 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. When two licenses in that account use the same run identifier, selected and baseline trend series retain their license identity so the results remain distinct.
Plan Gate
Portal Reporting is available on Enterprise. Use a valid Enterprise runner key when enabling WithPortalReporting.
Portal reporting setup
Use WithPortalReporting when an 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 include a top-right Light/Dark theme toggle and responsive offline SVG charts. Use exact-value tooltips, legends, zoom, pan, reset, the accessible expanded view, chart-title search, and grid-density controls to inspect dense results. 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_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_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_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_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_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_enterprise_runner_key")
.run();
})();Portal reporting checklist
Enables customer portal Run Reports and scenario trend history for this run. No separate vendor backend settings are required.
Portal Reporting is available on Enterprise.
Set a reporting interval when users should see periodic updates while a run is active.
An active raw-observation run can show a cumulative preview. After every expected result owner completes, the portal recalculates all deduplicated final load-phase outcomes and stores one exact history point per scenario and run. Success and failure detail remains separate, and long cross-run series are reduced without averaging percentile values or dropping endpoints.
SDKs split individual attempts into bounded, retry-safe batches, and every reporting-sink callback receives three retries by default after the first attempt, with 250 ms, 500 ms, and 1 second delays. Recovered callbacks add no final sink error or warning. Only exhausted raw-observation delivery counts as dropped observations; other exhausted callbacks are reported against that sink. Exception details remain in sanitized local logs rather than portable reports. Active heartbeats renew run authorization for long tests, and later reporting plus best-effort shutdown use the renewed authorization. Repeated or overlapping delivery of the same unchanged update produces one portal history point, while conflicting reuse of an update identity is rejected.
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 the signed-in account's available scenarios and runs on page load. Users can plot selected scenarios or choose a run to plot all scenarios in that run across 1D, 1W, 15D, 30D, or a custom period. Preset ranges define the metric window automatically, and From or To are used only when Custom is selected. Query fields include focus, run, metric, percentile, scenario, range, and chart.
Scenario mode opens by default and supports one or more scenarios across the selected period. Run mode uses the selected run only to choose its scenario set, then plots those scenarios historically across the selected period.
Trend points include their license identity. Selected and baseline runs with the same run identifier remain separate when they belong to different licenses in the signed-in account.
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 requests, failure rate, p50/p75/p95/p99 latency, and bytes.