Run Nightly E2E Tests on Staging
Schedule Opulent to run your end-to-end test suite against staging every night and file tickets for failures.
Set up API access and write the test playbook
Create a service user in the Opulent workspace with permission to create runs, then export the API key and organization ID. Connect Linear so Opulent can file tickets and Slack so it can post summaries.
The test logic lives in a playbook, a reusable, named set of steps Opulent follows every run. It defines how to run the suite, how to classify failures, and what each ticket must contain.
Playbook: !nightly-e2e Steps: 1. Run the Playwright suite against staging: PLAYWRIGHT_BASE_URL=https://staging.acme.dev npx playwright test --reporter=json 2. Parse the JSON results. 3. For each failing test, create a Linear ticket in the QA team: - Title: "[Nightly E2E] <test name>" - Description: error message, stack trace, test file path - Label: "nightly-e2e-failure" - Priority: High if in tests/critical/*, else Medium - Attach failure screenshots from the Playwright report 4. If all pass, post a green summary to #qa-results. 5. If any fail, post the count and a list of failing tests.
Use the same staging environment variables the team already trusts. Opulent needs the same database URLs and API keys your manual QA uses, stored as organization secrets.
Create the schedule via the API
Use the Opulent schedules API to register a recurring run. A cron expression at 2 AM UTC gives the suite time to finish before the team starts work.
Attach the playbook ID to the schedule so every run executes the same steps. Save the schedule ID returned in the response for later management.
POST /v3/organizations/{org_id}/schedules
{
"title": "Nightly E2E, staging",
"prompt": "Run the nightly E2E test suite against staging. Follow the playbook exactly.",
"schedule_type": "recurring",
"frequency": "0 2 * * *",
"playbook_id": "your-playbook-id"
}
Alternatives:
- "0 2 * * 1-5" for weeknights only
- "0 6 * * 1" for a Monday morning summaryVerify the first run
After the schedule fires, check that the suite executed, real failures created Linear tickets, and the Slack summary arrived. Distinguish flaky tests from real failures by checking whether the same test failed on a retry.
Common first-run issues: Opulent cannot reach staging because a secret is missing; the playbook points to the wrong test directory; or the Slack channel was not added to the integration.
What the team sees each morning
A green run posts one message with the pass count and the staging URL. A failing run posts the count, the list of failing tests, and links to the Linear tickets, each with a screenshot attached.
The Linear tickets become the source of truth for follow-up; the Slack summary keeps the team aligned without making them dig through CI logs.
Nightly E2E, staging All 142 tests passed (run #2026-02-10T02:00:00Z). Staging: https://staging.acme.dev Or, on failure: Nightly E2E: 4 of 142 tests failed - checkout/guest-flow.spec.ts (LIN-893) - admin/invite-user.spec.ts (LIN-894) - dashboard/search.spec.ts (LIN-895) - settings/billing.spec.ts (LIN-896) Tickets created in Linear with screenshots attached.
Sharpen the nightly test loop
When the same test flakes repeatedly, add a retry rule or tag it as flaky in the playbook so it does not drown out real failures. When a failure pattern repeats, add an eval that checks the playbook would file the ticket correctly.
Expand coverage over time: add critical user journeys, cross-browser runs, or API contract tests via Postman once the basic suite is reliable.
The natural chain: when a failing test points to a real bug, hand it to Debug a Bug Report End-to-End or Auto-Triage Bugs via Linear; when the failure is visual, use Catch Visual Regressions Before Every PR.