# Tigris bucket APIs failing?

Is there an outage on Tigris Data? I’m unable to upload content using a previously functional token with a mysterious “dispatch error.” When I sign into the Tigris Storage dashboard, I’m unable to load the bucket and the UI displays “Type error / Unable to load” messages.

## Solution

[**Tigris Status**](https://status.tigris.dev/incidents/01JKCBMAVT1W09PGVEAB4XCWMZ)

### Certain ISPs blocking fly.storage.tigris.dev

Due to malicious content that was previously uploaded to a public bucket, certain ISPs are blocking the service domain `fly.storage.tigris.dev`. The abuse has been addressed and the team is working with impacted ISPs to restore services.

This issue has been addressed.

Update: The Safari developer console shows the following:

Fetch API cannot load [https://fly.storage.tigris.dev/?IncludeVisibility=true&IncludeOwnerInfo=true&IncludeRegionsInfo=true](https://fly.storage.tigris.dev/?IncludeVisibility=true&IncludeOwnerInfo=true&IncludeRegionsInfo=true) due to access control checks.

No there is no outage. Could you let us know more about your bucket so that we can take a look what is happening? You can send the bucket details to help@tigrisdata.com?

This might be a network provider or DNS issue. When I connect using a VPN instead of my “naked” home internet connection, all of the above problems disappear. :man_shrugging:

I’ve cycled back and forth between VPN and not‑VPN several times. That pattern is completely reproducible.

I just ran into this today. It seems that:

```
dig @8.8.8.8 A fly.storage.tigris.dev
;; ANSWER SECTION:
fly.storage.tigris.dev.    30    IN    A    192.168.4.1
```

```
dig @8.8.8.8 A fly.storage.tigris.dev
;; ANSWER SECTION:
fly.storage.tigris.dev.    30    IN    A    192.168.4.1
```

Is returning a private IP address. I temporarily added their proper one to `/etc/hosts` as a workaround:

```
cat /etc/hosts | grep fly
149.248.213.147 fly.storage.tigris.dev
```

```
cat /etc/hosts | grep fly
149.248.213.147 fly.storage.tigris.dev
```

Unable to reproduce that dig result:

```
❯ dig @8.8.8.8 fly.storage.tigris.dev

; <<>> DiG 9.10.6 <<>> @8.8.8.8 fly.storage.tigris.dev
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35633
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;fly.storage.tigris.dev.        IN    A

;; ANSWER SECTION:
fly.storage.tigris.dev.    12    IN    A    149.248.213.147

;; Query time: 148 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Feb 05 18:04:54 EST 2025
;; MSG SIZE  rcvd: 67
```

```
❯ dig @8.8.8.8 fly.storage.tigris.dev

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;fly.storage.tigris.dev.        IN    A

;; ANSWER SECTION:
fly.storage.tigris.dev.    12    IN    A    149.248.213.147

;; Query time: 148 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Feb 05 18:04:54 EST 2025
;; MSG SIZE  rcvd: 67
```

Could you turn off VPN and clear the DNS resolve cache to reattempt? Could there be other utilities hijacking your DNS requests?

It’s possible – I am on a separate network now and can see the 149.x address. It’s probably ISP/network related as previously suggested. Just echoing I was seeing similar symptoms to OP.

## Solution

[**Tigris Status**](https://status.tigris.dev/incidents/01JKCBMAVT1W09PGVEAB4XCWMZ)

### Certain ISPs blocking fly.storage.tigris.dev

This issue has been addressed.