{"id":14767,"plugin_id":"plugin_asdk_app_6aa2109570b0819194170aae3449f6fb","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:10:07.899Z","digest":"18a73b402ae878651b491bce22e84712f0cd2b22925e67e1d39df2ace9579728","against":null,"payload":{"name":"results","description":"Analyze a finished Loadster load test or a monitor incident. Read the report, find the bottleneck or failure, explain it in plain terms, and record notes. Use when the user asks what happened in a load test, whether a test passed, why a monitor is failing, or what an incident means.","included_files":[],"skill_md_contents":"---\nname: results\ndescription: Analyze a finished Loadster load test or a monitor incident. Read the report, find the bottleneck or failure, explain it in plain terms, and record notes. Use when the user asks what happened in a load test, whether a test passed, why a monitor is failing, or what an incident means.\n---\n\n# Reading Loadster results\n\n## Load test reports\n\n1. Find the test with `list_load_tests` (filter to the user's project) and fetch it with `get_load_test_report`.\n   Read `get_documentation` on analyzing test results if you haven't already; the report has more in it than the\n   headline numbers.\n2. Look at the shape of the test before the averages. Response times and error rates plotted against the bot\n   count tell you *where* the system started to struggle. A flat response time with a rising error rate, a response\n   time that climbs with load, and throughput that plateaus while bots keep increasing are three different stories.\n3. Separate the categories of trouble:\n   - **Errors** (non-2xx, timeouts, failed validations): which steps, at what load, and did they cluster on one\n     endpoint?\n   - **Slowness**: which steps dominate, and does it get worse with load or is it just slow?\n   - **Script problems**: failures that happen at every load level, including a single bot, are usually the script\n     and not the system. Say so plainly rather than reporting them as a performance finding.\n4. Use `get_step_detail` on the play or test data when you need response bodies or captured values to explain a\n   failure.\n5. Give the user a conclusion, not a data dump: what broke or slowed down first, at roughly what load, and the most\n   likely reason based on the evidence. Be honest about what the report can't tell you; Loadster measures from\n   outside and doesn't see inside the application.\n6. Offer to record the conclusion with `update_load_test_notes`, and do it only after the user agrees, since notes\n   are visible to the whole team.\n\n## Monitor incidents\n\n1. `list_monitors` and `get_monitor` to understand what the monitor checks and how often.\n2. `list_incidents` and `get_incident` for the failure, then `list_monitor_cycles` around the incident time and\n   `get_monitor_cycle_detail` for the failing cycles. `get_monitoring_summary` gives the longer-term picture.\n3. Distinguish a real outage (consistent failures from all regions) from a flaky check (one region, one step,\n   intermittent) from a broken monitor (the site changed and the script's expectations didn't). Each has a\n   different fix.\n4. You can fix a monitor's script with `update_monitor`, and `disable_monitor` stops a noisy one. Enabling a monitor\n   and managing notification policies or maintenance windows are left to humans in the dashboard.\n\nIf anything in the tools made the analysis harder than it should have been, `submit_feedback` is there for it.\nOptional, and about the tools rather than the report or the user's data.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}