Estora reference data and screenshots
All images are for reference only. Screens use synthetic Estora development data and do not describe real service availability.
On this page
All images are for reference only. Screenshots use a local SignalHub installation and the Estora development organization. Synthetic incidents, monitor results, metric points, traffic, subscribers and destinations illustrate the product. They are not reports of real Estora service availability, production incidents, customer adoption or performance.
Dataset
The documentation enrichment preserves Estora's existing organization, account, Payment Health page, services and records. It adds named [Reference] records:
| Area | Added examples |
|---|---|
| Pages | Estora service hub, operational platform page, private operations page and audience-specific partner page. |
| Services | Seven payment infrastructure services on Payment Health and seven on the reference platform page, with a 90-day synthetic baseline. |
| Monitoring | HTTP, Keyword, TCP, DNS, TLS, ICMP and Heartbeat examples; 168 synthetic hourly results and latency points per type. |
| Events | Investigating, Identified, Monitoring and Resolved incidents; historical disruptions; Scheduled, In progress, Verifying and Completed maintenance; one hidden internal incident. |
| Audience | Twelve sample email subscribers, including an example quarantine state. All remain unverified. |
| Destinations | Two disabled sample destinations: Slack and webhook. |
| People | Three disabled synthetic accounts with page-scoped Incident Manager, Responder and Viewer roles. |
| Audit | A truthful reference-data creation event, written through the normal audit writer and filtered for screenshots. |
| Analytics | Thirty days of simulated aggregates on the Estora platform reference page. |
Sample monitors stay paused, their automation/notification actions are disabled, and destination URLs use reserved example domains. No delivery jobs are created. The script does not change existing passwords, roles, provider settings or installation MFA policy. Rerunning it reuses named reference records and leaves existing history intact.
Recreate the examples
Run only against a local disposable development installation that already has organization slug estora and page slug payment-health:
NODE_ENV=development ALLOW_DEV_SEED=true CONFIRM_ESTORA_DOCUMENTATION=estora \
node --env-file-if-exists=.env --import tsx scripts/docs/seed-estora.ts
The tool reads the application's normal environment or wizard configuration in memory. The public website does not contain the local database credentials or runtime configuration. The tool deliberately rejects non-loopback database hosts.
Capture and publish
Use the Estora organization in a signed-in development session. Capture actual rendered screens after the page has loaded. Hide the Next.js development indicator through its Preferences menu, and avoid usable credentials, one-time codes and customer data. Filter platform-wide people and audit views to synthetic Estora records. Setup and authentication screens are installation flows rather than organization-specific pages.
Setup and MFA references use a separate local database with synthetic Estora accounts and independent application keys. After capture, every account is disabled, sessions and authenticator/recovery material are removed, and pending removal requests are closed before images are copied into the public website. Any QR code or setup key visible in an enrollment reference is therefore retired. Recovery-code lists are omitted; the guide shows the regeneration confirmation instead. The subscription example shows the actual worker-unavailable state; email and SMS entry require a healthy delivery worker and a configured provider.
Native browser captures are retained with the application’s authoring files in docs/captures/estora/, outside the public marketing project. Set CAPTURE_SOURCE_DIR to use another capture folder. The corresponding PNGs in docs/screenshots/ and compressed WebP copies in public/docs/ must be refreshed together. The standalone HTML export keeps only the published assets in the marketing project’s assets/screenshots/, so it does not depend on an application /docs URL or deploy duplicate original captures.
From the usual sibling checkout layout, synchronize screenshots with node scripts/docs/sync-screenshots.mjs in the application, then rebuild the public documents and run the marketing project checks:
cd ../signalhub
npm ci
SIGNALHUB_SOURCE_DIR=../status npm run docs:sync
npm test
The public website is at http://localhost:3300/ and its documentation index is at http://localhost:3300/docs/. Publish the standalone website files to your own static host; see website deployment.