What does the Nashville TN 311 data include?

One table, service requests, with one row per service request.

Do I need an account with Nashville TN 311?

No. The data is public, so there is nothing to sign up for and nothing to paste in.

Will running it again create duplicate rows?

No. Each row is stored once, by its key: when a run reads a row that is already there, it replaces that copy instead of adding a second one.

Do I need to write code?

No. Ingest builds, runs and maintains the connector. Someone with access to your warehouse connects it once, following a short guide.

Nashville TN 311

Public data

Ready to useNo account needed

Service requests from Nashville and the surrounding area opened since 2017. Ingest delivers this data to a data warehouse you own as one table, and updates it on the schedule you choose. There is no code to write and nothing to install.

2.1 millionservice requests as of September 2026
About 5,600new service requests a week
1 tableone row per service request

What people use it for

Track patterns across monthsMonitor the last year to understand how problems shift over time.
Find problem neighborhoodsPlot requests to see which parts of the area report most frequently.

What you get

Table	Each row is
Service requests `featureserver`	One service request

Good to know

The first run loads the last 365 days. After that, each run keeps the last 365 days current, re-reading a day once its copy is 7 or more days old. Older requests keep the values they had when last read.

How it works

Choose Nashville TN 311. The data is public, so there is nothing to sign in to.
Pick where it goes. BigQuery, Snowflake, Databricks, Redshift and 10 more, in an account you own.
Pick a schedule. Daily is the default, and weekly and monthly are there too.
Ingest runs it from then on. If a run fails, your dashboard shows which table and why.

Questions

What does the Nashville TN 311 data include?: One table, service requests, with one row per service request.
Do I need an account with Nashville TN 311?: No. The data is public, so there is nothing to sign up for and nothing to paste in.
Which warehouses can Nashville TN 311 data go to?: Amazon S3, Google Cloud Storage, Azure Blob Storage, Apache Iceberg, Ingest Managed Lakehouse, MotherDuck, Postgres, Amazon Athena, Databricks, Redshift, BigQuery, ClickHouse, MySQL / generic SQL and Snowflake, in an account you own.
How fresh is the data?: As fresh as your schedule: daily by default, or weekly or monthly. Schedules as often as every 15 minutes are on the Enterprise plan. The first run loads the last 365 days. After that, each run keeps the last 365 days current, re-reading a day once its copy is 7 or more days old. Older requests keep the values they had when last read.
Will running it again create duplicate rows?: No. Each row is stored once, by its key: when a run reads a row that is already there, it replaces that copy instead of adding a second one.
Do I need to write code?: No. Ingest builds, runs and maintains the connector. Someone with access to your warehouse connects it once, following a short guide.

For your data team: technical reference

Connector nashville_311, version 0.1.0, a REST source, status beta, authentication none.

Vendor documentation: https://services2.arcgis.com/HdTo6HJqh92wn4D8/arcgis/rest/services/hubNashville_(311)_Service_Requests_1/FeatureServer/0

Configuration

No configuration required.

Resources

Resource	Status	Plan	Write	Primary key	Overrides
`featureserver` Public service requests logged by Metro Nashville's hubNashville 311. The publisher states the layer covers requests opened since 2017 and is updated daily; it accumulates rather than rolling off (2,083,613 records counted independently on 2026-09-14). Rows are read in creation-day windows of Date_Time_Opened. By default the last 365 completed UTC days are in scope; the current UTC day becomes eligible once it completes. Each window is a half-open UTC interval [00:00:00, 00:00:00) of the requested day, so a request opened exactly at midnight belongs only to that following day and no window overlaps another. Completed days inside the horizon are re-read staleness_days after their last successful read, so later status changes and closures are captured on a subsequent run; raising lookback_days backfills older creation days over subsequent runs, and requests older than the horizon keep their last synced values while requests removed from the source are retained in the destination. The layer exposes no general updated-date field, so a creation-only watermark would miss later edits; re-reading each creation day is how closures and status changes are picked up, and the cost scales with the horizon. Date fields are the layer's native Unix epoch MILLISECONDS (UTC) and are preserved as bigint; Date_Time_Closed is null for still-open requests. Rows are keyed by Request__ (Request #), the unique service-request number assigned by hubNashville. Older completed days wait longer between reads, becoming eligible again only after the longer of the refresh interval and a twentieth of their age at their last read (with the default interval, a day read at 280 days old waits 14 days).	beta	window	merge	`Request__`	lookback_days, staleness_days