Servers

Servers receive and process data for a project. A source’s Ingest tab shows the project’s endpoint when one is available.

Trial and paid servers

The free trial starts one server in your team’s first project and grants the team 72 server-hours of compute credit. A payment method is required to add more servers. Credits are shared across projects: two running servers use the same 72-hour balance in 36 hours. Manage Servers shows the monthly cost before you confirm a change.

The three days start when the trial server first comes up. Without a payment method, the initial server pauses after those three days. Billable usage ends at the trial deadline, including when cleanup runs late. With a card, servers keep running and use any remaining credits before paid usage begins. Unused credits do not expire. Tailglow staff can extend a trial, which adds the matching server-hours and brings back a paused trial server. See Billing for month boundaries, resume rules, and the AI and storage allowances every team has.

Manage server count

1. Open Servers in the project sidebar.
2. Click Manage Servers.
3. Set the desired server count.
4. Review the consequence and confirm it.

Scaling up uses Add server or Add servers and starts provisioning after you confirm. Scaling down, including scaling to zero, requires a hold-to-confirm action. Scaling to zero stops ingestion, so events sent while no server is running are not stored or recoverable.

Scaling during a platform update

Tailglow updates every server to new platform versions one project at a time, reserving the capacity each update needs before it starts. While an update is in progress, a change to the server count is queued instead of applied: Manage Servers confirms the request, the Servers page shows the queued count, and the change starts automatically when the update finishes. Adding servers to a project that has not finished moving to the current platform version is queued the same way; removing servers is not.

To cancel a queued change, select Cancel queued change on the Servers page, or set the count back to the number of servers the project runs. A newer request replaces an older one. A project with no servers yet is not held back; its first server starts right away. A paused trial server that resumes after you add a payment method also waits for the update to finish.

Statuses

A new server starts as provisioning and becomes active after setup. Scaling down changes it to terminating while Tailglow drains and removes it. Scaling up later creates a new server.

Server analytics

Server detail pages show resource usage for the selected server. Project Ingest Pipeline shows pending records, throughput, and errors across every server in the project, including temporary deployment servers. You can select a time range or brush across a chart to focus on a smaller window.

The current queue counts valid spooled records awaiting write, including records being processed. It refreshes independently of the selected chart window. When queues change during the observation, Tailglow counts the durable records it can confirm and marks the pending count with ≈. If a current server’s queue cannot be read or a concurrent write’s outcome is unknown, the queue is unavailable instead of showing an uncertain total. A stale reading means the last complete or estimated snapshot is too old to confirm the current queue. The single-line summary shows processed records from the last completed minute alongside the current pending count. The error button appears when the selected chart range contains recorded errors; errors count rejected requests and dropped frames.

The summary shows a skeleton while its first request loads and keeps existing readings visible during refreshes. Delayed or unavailable measurements are labeled separately, so an available queue or processed count remains visible. A retry control appears after a failed refresh or when neither current reading is available.

Historical pending values are average queue occupancy, so they can contain fractions. Older history recorded in request frames has gaps in the pending-record series.

Throughput is counted in the minute each spool batch completes. Delayed sampling or shutdown uploads preserve that minute, even when resource measurements for it are unavailable. This does not reconstruct missing historical measurements.

Missing measurements appear as gaps, including when a server’s contribution cannot be read. Pending, throughput, and errors can be available independently. Live polling pauses in background tabs.

The analytics API supports windows up to 48 hours with minute buckets or 30 days with hour buckets. Future end times are limited to the current time.

Measured values in the current chart bucket show (so far) until the bucket ends. For example, at 9:35 an hourly bucket starting at 9:00 is still in progress.