HourTab

Blog › ICP guides

Database administrator on retainer: tracking DBA advisory and demonstrating database operational value between performance incidents and major migrations

July 18, 2026 · ~17 min read

The major database performance incident and the schema migration project are the visible database events. When an engineering director presents the system reliability metrics to the CTO, when a VP Engineering reports the database health status to stakeholders, when a backend team lead reviews the quarterly performance trends with the product team — those are the artifacts on the table: the P1 incident where the orders query degraded from 40ms to 1,840ms after the data volume crossed 40 million rows, the successful zero-downtime migration that added a NOT NULL column to the 85-million-row accounts table using the expand-migrate-contract pattern, the backup validation that confirmed restoration from the prior day's base backup completed within the four-hour recovery time objective. What none of those artifacts shows is the continuous database operational governance between those visible milestones, or whether that ongoing advisory is what prevented the autovacuum configuration on the sessions table from allowing dead tuples to accumulate to 8.3 million rows and the sessions index to bloat from 124MB to 1.9GB adding 40ms to every session lookup, identified the replication lag spike approaching the 30-second recovery point objective threshold during the batch export job and recommended the replication slot configuration change that prevented WAL accumulation from forcing an unplanned primary restart.

The query performance review that identified a sequential scan on a 47-million-row orders table where a composite index on (account_id, created_at DESC) existed but the query's WHERE clause filtering on both account_id and status IN ($2, $3) was not covered by the index because status was not included as a third index column — where the query planner selected an index scan on the account_id column that returned 99% of rows for the given account before applying the status filter at the table level, and where at the 99th selectivity percentile the planner's cost model estimated the sequential scan as cheaper than the index scan with the large intermediate row set — where the redesigned composite index on (account_id, status, created_at DESC) allowed the planner to use both the account and status filters within the index scan and reduce the execution plan cost from 94,283.00 to 0.57, reducing the query execution time from 1,840ms to 4ms — that prevented the query from degrading further as the table grew from 47 million to 80 million rows over the following quarter. The autovacuum governance session that identified that the pg_stat_user_tables dead tuple count for the sessions table had reached 8.3 million rows against 2.1 million live rows because the session expiry job's DELETE rate of 30,000 rows per minute during peak hours exceeded the autovacuum worker's throughput at the default 20ms cost delay setting — where the growing dead tuple accumulation had caused index bloat on the sessions_user_id_idx that expanded from 124MB to 1.9GB and was adding 40ms to every session validation query that used it — that identified the per-table autovacuum parameter adjustment required before the index bloat reached the point where a REINDEX CONCURRENTLY would require a multi-hour maintenance window.

The backup recovery test that executed a point-in-time recovery from the prior night's base backup and WAL archive to a recovery target of two hours before the test start time — where the recovery completed successfully to the target LSN but the total restoration time was 3 hours 47 minutes against a four-hour recovery time objective that would have been met with 13 minutes of margin if the recovery had started immediately at the incident declaration time but would have missed the RTO if the incident required 30 minutes of diagnosis before recovery was initiated — where the finding produced a recommendation to pre-warm the recovery environment standby to reduce the restoration startup time and bring the effective RTO within the four-hour target with reasonable diagnostic lead time — that converted a formal RTO compliance that masked a practical RTO risk into an operational adjustment before the risk was exposed by an actual recovery event. The replication health advisory that identified a replication lag spike reaching 18 seconds during the weekly batch export job that ran at 3AM and issued 2.3 million UPDATE statements in a single transaction — where the lag spike occurred because the WAL records for the 2.3-million-row transaction were replayed on the replica as a single transaction requiring the replica's apply worker to hold locks for the duration of the replay, blocking concurrent read queries on the replica for the 14 seconds the replay required — that recommended converting the batch export job to smaller transactions of 10,000 rows each that produced continuous replication with maximum lag of 1.2 seconds rather than a 18-second spike, and that identified a replication slot configured for a no-longer-connected logical replication consumer that was preventing WAL segment cleanup and growing the pg_wal directory at 4GB per day.

Database administrators and DBA consultants on monthly retainer do their most consequential work in the continuous stretches between performance incidents and major migrations: the query performance governance that identifies sequential scan conditions and missing index coverage before they produce user-visible latency regressions at production data volumes; the autovacuum and table maintenance governance that prevents dead tuple accumulation and index bloat from degrading query performance on tables with high write rates; the replication health monitoring that identifies lag trajectories and configuration risks before they approach the recovery point objective; the connection pool calibration that prevents connection exhaustion and connection pool queuing under traffic spikes; and the backup and recovery testing that validates whether the backup infrastructure will actually restore within the recovery time objective when a genuine recovery event requires it. All of that advisory is invisible to the engineering director and CTO without a work log that connects the ongoing database operational governance to the query performance, replication reliability, and recovery readiness it maintains.

DBA versus data engineer versus backend engineer: the primary operational distinctions

Three engineering advisory roles interact with databases in ways that are routinely conflated in engineering leadership conversations: the database administrator, the data engineer, and the backend engineer. The conflation produces situations where the OLTP database operational governance function — the discipline that covers server configuration, autovacuum and maintenance processes, physical storage organization, replication health, connection pool management, and backup and recovery infrastructure — is either missing, distributed across advisors without clear ownership, or assigned to advisors whose database expertise is the query layer rather than the server operational layer.

A data engineer on retainer governs data pipeline infrastructure: the ingestion pipelines that extract data from OLTP source systems and load it into the analytical data warehouse; the transformation layer that converts raw ingested data into the cleaned, normalized, and modeled form that analytical queries require; the data quality checks that validate pipeline output and alert when the data delivered to analysts is incorrect or incomplete; and the warehouse schema design (star schema, Kimball dimensional model, OBT for specific analytical access patterns) that determines query performance on analytical workloads. A data engineer who is designing the architecture of a Redshift cluster or a BigQuery dataset is working with the analytical database configuration that governs warehouse query performance, not the OLTP database server configuration that governs transaction throughput, autovacuum, and replication. A data engineer who is not reviewing pg_stat_user_tables, pg_stat_replication, or pg_stat_statements for the production PostgreSQL OLTP database is not providing the OLTP operational governance that prevents autovacuum lag and replication failures.

A backend engineer on retainer governs application-layer database interactions: the ORM query patterns that determine how the application's object-relational mapping generates SQL for specific operations; the database call frequency within a single request handler (N+1 query detection, bulk fetch vs. per-row fetch patterns); the transaction boundary design that determines which operations are grouped into a single database transaction and what isolation level is required; and the application-level caching strategy that determines which database reads can be served from application cache rather than requiring a database round trip. A backend engineer asking “why does this endpoint make 47 database calls for a request that should require one query?” is asking an application-layer question. A DBA asking “why is the orders table's idx_orders_account_status index consuming 47 buffer gets per row returned when the expected selectivity is 0.3%?” is asking a server-layer question. Both questions are about database query performance, but one is answered by modifying the application code and the other is answered by analyzing the query execution plan and server statistics.

A database administrator or DBA consultant on retainer governs the OLTP database server's operational health: the PostgreSQL or MySQL server configuration parameters that determine memory allocation for shared buffers, working memory for sort and hash operations, effective cache size for planner cost estimation, and the connection limit that constrains maximum concurrent database sessions; the autovacuum configuration that controls how quickly dead tuples from UPDATE and DELETE operations are reclaimed and how aggressively index bloat is reduced by vacuum passes; the physical storage organization including tablespace allocation, index physical order, and the bloat ratios that determine when a REINDEX CONCURRENTLY or VACUUM FULL is warranted despite its operational cost; the replication configuration that governs WAL shipping, streaming replication, replication slot behavior, and the lag monitoring that validates whether the replica can serve as a failover target within the recovery point objective; the connection pool configuration that governs PgBouncer or RDS Proxy pool mode, pool size, and connection lifetime; and the backup and recovery infrastructure that determines whether a point-in-time recovery is achievable within the recovery time objective for the failure scenarios the backup system is designed to address.

What ongoing DBA retainer advisory actually consists of

Query performance tuning and index design

Database query performance degrades with data volume in ways that are not visible in development or staging environments where table sizes are orders of magnitude smaller than production. A query that executes in 3ms against a 50,000-row development table executes in 1,840ms against a 47-million-row production table if the query planner selects a sequential scan at the larger data volume, because the planner's cost model estimates that a sequential scan is cheaper than an index scan when the index returns too large a proportion of the table's rows to justify the random I/O cost of the index lookup. The planner's selectivity estimates are based on table statistics collected by ANALYZE using the default_statistics_target setting, and queries on columns with skewed value distributions (account IDs where the top 0.1% of accounts generate 40% of rows, status values where 98% of orders are in the completed state) can produce significantly inaccurate selectivity estimates when the statistics target is too low to capture the tail distribution accurately.

Query performance tuning on retainer covers the regular review of pg_stat_statements for queries with high total execution time, high mean execution time, or high sequential scan counts; the EXPLAIN ANALYZE analysis of slow queries to identify plan selection (sequential scan vs. index scan, nested loop vs. hash join, sort vs. index scan for ORDER BY), the row estimates vs. actual rows at each plan node, and the buffer hit vs. block read ratio that indicates whether the query's working set fits in the shared buffer cache; the index design advisory that recommends composite index column ordering based on the query's access pattern selectivity, the inclusion of filter columns that would otherwise require a table fetch (covering indexes), and the partial index definitions that reduce index size for queries that consistently filter on a constant value; and the statistics target adjustment for columns with skewed distributions where the planner's estimates are inaccurate enough to produce suboptimal plan selection.

On retainer: reviewing the slow query log and pg_stat_statements for performance regressions introduced by new data volume, schema changes, or query pattern changes; advising on index designs for new query patterns introduced by feature releases before they are deployed to production data volumes; and analyzing execution plans for the queries that represent the highest cumulative database load to identify plan selection inefficiencies.

Autovacuum and table maintenance governance

PostgreSQL's Multi-Version Concurrency Control (MVCC) model produces dead tuples as a byproduct of UPDATE and DELETE operations: each UPDATE produces a new tuple version while the old version becomes a dead tuple that cannot be removed until all transactions that might need to read the old version have completed. The autovacuum background process reclaims dead tuple space and updates table statistics; its default configuration is tuned for moderate write rates and balanced resource consumption rather than for tables with high UPDATE or DELETE rates where the default cost delay throttling prevents the autovacuum worker from keeping pace with the write volume. A table where autovacuum cannot keep pace with dead tuple accumulation exhibits growing bloat: the physical size of the table's heap and indexes exceeds the live data size by a growing factor, sequential scans take longer because they must read more physical pages, and index scans become less efficient because dead tuple entries in the index leaf pages require more I/O per live row returned.

Autovacuum and table maintenance governance on retainer covers the regular monitoring of pg_stat_user_tables dead tuple counts and bloat ratios for tables with high write rates; the per-table autovacuum parameter tuning (autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limit, autovacuum_vacuum_scale_factor, autovacuum_vacuum_threshold) that adjusts the autovacuum worker's throughput and trigger sensitivity for tables where the default configuration is insufficient; the identification of tables and indexes that have accumulated sufficient bloat to warrant a manual VACUUM ANALYZE or REINDEX CONCURRENTLY operation; the scheduling advisory for manual maintenance operations that minimize impact on application performance by targeting low-traffic windows and using the concurrent variants that do not take exclusive table locks; and the transaction ID wraparound monitoring that identifies databases approaching the transaction ID wraparound threshold that triggers PostgreSQL's emergency vacuum mode.

On retainer: reviewing dead tuple counts and bloat ratios for high-write tables to identify autovacuum lag conditions before they produce visible query performance degradation; advising on per-table autovacuum parameter adjustments for tables where monitoring indicates the default configuration is insufficient; and scheduling manual maintenance operations for tables that have accumulated sufficient bloat to warrant intervention.

Replication health monitoring

PostgreSQL streaming replication delivers WAL records from the primary server to one or more replica servers, where a replica's recovery process replays the WAL records to maintain a consistent copy of the primary's data. The replication lag — the difference between the primary's current WAL position and the replica's applied WAL position — determines the recovery point objective achievable with the current replication configuration: if the primary fails at a moment when the replica is 45 seconds behind, a failover to the replica loses up to 45 seconds of committed transactions. Replication lag is driven by the write volume on the primary, the network throughput between primary and replica, and the replay throughput on the replica's apply worker — and spikes in replication lag are frequently caused by specific application patterns (large single transactions, bulk import operations, DDL changes that produce large WAL records) rather than sustained high write rates.

Replication health monitoring on retainer covers the tracking of primary-to-replica replication lag via pg_stat_replication against the recovery point objective; the identification of write patterns that drive lag spikes (large transactions, bulk operations, DDL changes) and the advisory on modifying those patterns to reduce their lag impact; the monitoring of replication slot configurations to identify slots that are not being consumed and are preventing WAL segment cleanup from advancing, producing unbounded pg_wal directory growth that risks disk exhaustion on the primary; and the evaluation of the replica's readiness to serve as a failover target by confirming that the replica's configuration, connection pool, and monitored metrics match the requirements for a failover to succeed within the recovery time objective.

On retainer: monitoring replication lag against the recovery point objective to identify trajectories approaching the RPO threshold before they produce a compliance gap; advising on write pattern changes for application operations that produce replication lag spikes disproportionate to their data volume; and auditing replication slot configurations to identify unused slots that are preventing WAL cleanup.

Connection pool configuration advisory

PostgreSQL's process-per-connection model allocates substantial memory per connection: a PostgreSQL server configured with max_connections = 500 reserves memory for up to 500 concurrent database backends, and the actual memory consumption per backend including working memory allocations for sort and hash operations can reach 50–100MB per active connection on a busy server. Connection pool managers (PgBouncer, RDS Proxy) reduce the connection demand on the database server by multiplexing many application-layer connections through a smaller number of persistent database connections, but connection pool misconfiguration produces its own failure modes: a pool size too small for the application's concurrent query demand produces connection queuing where application threads wait for pool slots, visible as latency spikes correlated with traffic volume increases; a pool mode selection (session-pooling vs. transaction-pooling vs. statement-pooling) mismatched to the application's use of session-state features (prepared statements, advisory locks, SET parameters) produces connection state corruption where session state from one application thread is visible to another.

Connection pool configuration advisory on retainer covers the evaluation of PgBouncer or RDS Proxy pool size against the application's observed concurrent query demand and the database server's max_connections limit; the pool mode selection advisory based on the application's use of session-state features that constrain which pool modes are compatible with correct application behavior; the connection lifetime and idle timeout configuration that prevents stale connections from accumulating in the pool when the database server is restarted or network interruptions drop connections without notifying the pool manager; and the connection pool health metrics (pool utilization, connection acquisition wait time, connection error rate) that identify pool saturation conditions before they produce widespread application latency regressions.

On retainer: reviewing connection pool utilization and connection acquisition latency metrics to identify saturation conditions before they produce application latency regressions; advising on pool size adjustments, connection lifetime tuning, and pool mode selection for new application features that introduce new connection demand patterns; and reviewing connection pool configuration after database server changes (max_connections adjustments, server restarts, failover events) that affect the pool's connection state.

Backup and recovery testing

A backup system that has never been tested for recovery is a hypothesis, not a recovery capability. The gap between the backup system's design intent and its actual behavior under recovery conditions is revealed only by executing a recovery — and engineering organizations that discover this gap during an actual incident are recovering their data under time pressure from leadership while simultaneously debugging the recovery process for the first time. Point-in-time recovery (PITR) requires both a consistent base backup and an unbroken WAL archive from the base backup LSN to the recovery target time: a WAL archive gap — where a WAL segment failed to archive and the gap was not detected — prevents PITR from recovering past the gap, producing a recovery that stops at a point in time the team did not intend and losing the transactions between the gap and the recovery target.

Backup and recovery testing on retainer covers the validation that backup jobs are completing successfully and that the resulting backup artifacts are usable for recovery (not just that the backup job did not report an error, but that the backup can be mounted and restored); the periodic execution of recovery tests against backup snapshots in an isolated environment that confirms the recovery process actually restores the database to the target state within the recovery time objective; the validation of WAL archive completeness for point-in-time recovery capability; and the recovery procedure documentation review that confirms the documented steps are accurate, complete, and executable by the on-call engineer who will need to initiate recovery under time pressure.

On retainer: executing monthly recovery tests against the prior night's base backup to validate that the recovery process completes within the recovery time objective; reviewing WAL archive health and coverage to confirm PITR capability from the base backup to the current time; and advising on backup schedule adjustments, archive storage configuration, and recovery environment pre-warming that reduce the recovery time under actual incident conditions.

The work that most commonly goes unlogged in a DBA retainer

The most consistently underlogged DBA advisory work falls into two patterns: monitoring work that confirmed the database's operational health was within target, and advisory work that prevented a database performance or reliability event rather than responding to one. Both patterns produce the misimpression that the retainer period was quiet when it contained the continuous database operational governance that enables stable query performance, replication reliability, and recovery readiness.

Performance monitoring reviews that confirmed all queries were within target are the canonical underlogging case in DBA retainers. A review of the pg_stat_statements output that confirmed no query's mean execution time exceeded the 100ms threshold, that no table's sequential scan ratio exceeded the 15% threshold on queries with selective filters, and that all high-write tables' dead tuple counts were within the autovacuum trigger threshold — that review required the same performance monitoring platform analysis, the same execution plan evaluation for queries approaching the threshold, and the same autovacuum health interpretation as a session that identified a sequential scan regression. The engineering organization that knows its query performance was reviewed and confirmed healthy is in a materially different position than one that assumed it was healthy without the monitoring review to support it — particularly as data volumes grow and previously efficient queries approach the selectivity thresholds where the planner's cost model produces sequential scan decisions.

Replication health checks that confirmed lag was within the recovery point objective are consistently underlogged by DBA consultants who conflate “replication lag was within target” with “no replication monitoring was performed.” Reviewing the pg_stat_replication lag metrics, confirming that no spike exceeded the 30-second RPO threshold, identifying the batch job that produced the largest single-session lag spike and confirming the spike resolved within the expected window, and confirming that no replication slots were accumulating unconsumed WAL — that required the same replication monitoring platform analysis, the same lag spike attribution to specific write patterns, and the same replication slot audit as a session that identified a 4-minute lag spike approaching the RPO threshold. The confirmed health check is the positive outcome of replication monitoring; logging only sessions with replication findings systematically understates the replication governance work performed.

Backup recovery test sessions are consistently underlogged because the test that confirmed restoration completed within the RTO produced no corrective action items — and monitoring sessions that produce confirmations rather than findings are viewed as administrative rather than advisory. A recovery test that executed point-in-time recovery from the prior night's base backup and WAL archive, confirmed the WAL archive was complete from the base backup LSN through the recovery target time, and confirmed restoration to the target time completed in 3 hours 12 minutes against a four-hour RTO — with 48 minutes of margin that allows for the diagnostic lead time before recovery initiation — required the same recovery infrastructure knowledge, WAL archive analysis, and restoration procedure execution as a test that discovered a WAL archive gap. The recovery test that confirms RTO compliance with margin is not less valuable than the test that discovers a gap; it is more valuable to the engineering organization, because it confirms the recovery infrastructure will work when the actual incident requires it.

Retainer rates for database administrators and DBA consultants

Database administrator and DBA consultant retainer rates vary with database platform specialization depth (PostgreSQL, MySQL, Oracle, SQL Server), the scale of the systems being governed (row counts, transaction rates, replication topology complexity), and the criticality of the databases in scope (revenue-critical OLTP vs. reporting replicas):

Advisory-only DBA retainers — query performance governance, autovacuum monitoring, replication health, connection pool advisory, and backup testing — are typically priced differently from engagements that include direct production database modifications, index creation and dropping, autovacuum parameter changes applied to production servers, and schema migration execution. The advisory function that prevents database operational failures through governance is distinct from the operational function that executes the maintenance tasks the advisory identifies; both have retainer rate structures appropriate to their scope, access requirements, and risk profile.

Making DBA retainer advisory visible to engineering leadership

The central challenge in database administrator retainer relationships is that the value of ongoing database operational governance is structurally invisible to the engineering director and CTO when the advisory is working as intended: the consistent sub-100ms query performance on the orders endpoint does not show the composite index redesign that prevented the sequential scan regression at 47 million rows; the 99.8% replication availability metric does not show the replication slot audit that identified the unconsumed slot accumulating WAL at 4GB per day before it caused disk exhaustion on the primary; the successful point-in-time recovery test does not show the WAL archive completeness validation that confirmed PITR capability and the 48 minutes of recovery time margin that makes the RTO achievable with diagnostic lead time. The value of DBA advisory is experienced as the absence of the database operational failures it prevents — and the engineering leader who does not see those failures cannot easily explain why the databases are performing consistently without a record of the governance work that produced the consistency.

The work log that connects advisory sessions to specific query performance findings, autovacuum governance outcomes, replication health checks, and backup recovery tests is the primary mechanism for making DBA advisory value visible over time. An entry that records the sequential scan condition identified, the composite index redesign that addressed it, and the execution plan cost reduction from 94,283.00 to 0.57 gives the engineering director a concrete example of what the query performance governance function prevents. An entry that records the sessions table dead tuple accumulation, the autovacuum cost delay adjustment, and the index bloat trajectory before and after the tuning allows the VP Engineering to understand what the autovacuum governance function produces. An entry that records the recovery test target time, the WAL archive completeness confirmation, and the 3 hours 12 minutes restoration time against the four-hour RTO gives the CTO visibility into the recovery readiness that the backup and recovery testing function maintains.

A retainer dashboard that makes the DBA consultant's work log visible to the engineering director or CTO without requiring the consultant to send a monthly database health report email converts the work log from a private advisory record into a shared artifact of the engagement. The engineering leader who can see the full sprint's query performance reviews, autovacuum governance sessions, replication health checks, connection pool advisory, and backup recovery tests in a single URL understands immediately what the database retainer is producing — and has a concrete record to reference when making renewal decisions, planning infrastructure upgrades, or explaining the database operational investment to stakeholders who ask why the application's query performance has been stable while data volumes have grown by 3x over the past year.

Frequently asked questions

What does a database administrator on retainer typically do?

A database administrator or DBA consultant on monthly retainer typically provides query performance tuning and index design (slow query log review, execution plan analysis, composite index column ordering advisory), autovacuum and table maintenance governance (dead tuple monitoring, per-table autovacuum parameter tuning, bloat assessment), replication health monitoring (streaming replication lag tracking against RPO, replication slot auditing, WAL accumulation risk), connection pool configuration advisory (PgBouncer/RDS Proxy pool size and pool mode calibration), and backup and recovery testing (periodic PITR validation against RTO, WAL archive completeness confirmation). The performance incident is the visible event; the continuous database operational governance between incidents is the ongoing retainer function.

How is a database administrator different from a data engineer or backend engineer on retainer?

A database administrator focuses on OLTP database server operational health: server configuration parameters, autovacuum and table maintenance processes, execution plan analysis at the server statistics level, replication configuration and lag monitoring, connection pool management, and backup and recovery infrastructure. A data engineer on retainer focuses on data pipeline infrastructure: ingestion pipelines from source systems into the analytical warehouse, data quality governance for pipeline output, and analytical schema design for warehouse query patterns. A backend engineer on retainer focuses on application-layer database interactions: ORM query patterns, transaction boundary design, N+1 query elimination, and application-level caching strategy. All three roles interact with databases; the DBA is the advisor responsible for the server-layer operational health that determines whether the queries the backend engineer writes and the data the data engineer ingests perform correctly at production scale.

What DBA retainer work is most commonly underlogged?

Performance monitoring reviews that confirmed all queries were within target, replication health checks that confirmed lag was within the recovery point objective, and backup recovery tests that confirmed the restoration completed within the recovery time objective. All represent genuine database operational governance whose value is in the ongoing confirmation and failure prevention rather than in a finding list — and all are systematically underlogged by consultants who conflate “no database issue found” with “no database governance performed.”

What should a database administrator retainer agreement include?

Read access to the database monitoring infrastructure, scope boundary between advisory and direct production database modification, replication and backup system access definition, disaster recovery test authorization scope, and a shared work log visible to engineering leadership that documents the ongoing query performance reviews, autovacuum governance sessions, replication health checks, connection pool advisory, and backup recovery tests the retainer produces between performance incidents and major migrations.

How should DBA retainer hours be logged?

Log entries should capture the DBA function (query performance tuning, index design, autovacuum governance, replication monitoring, connection pool advisory, backup recovery testing, schema migration advisory), the table or system reviewed, the operational concern analyzed, and the finding or recommendation. Log every session, including monitoring reviews that confirmed all metrics were within target and recovery tests that confirmed RTO compliance. The performance review that confirmed no regression required the same analysis as the review that identified one; logging only sessions with findings systematically understates the volume of database operational governance work and misrepresents the retainer's value to the engineering leadership making the renewal decision.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark. No client login required. See how it works →